{"id":16105852,"url":"https://github.com/devlights/try-docker","last_synced_at":"2025-04-06T03:13:40.575Z","repository":{"id":43869845,"uuid":"418314283","full_name":"devlights/try-docker","owner":"devlights","description":"This is a repository for learning Docker. (for myself)","archived":false,"fork":false,"pushed_at":"2022-02-16T01:08:22.000Z","size":165,"stargazers_count":0,"open_issues_count":3,"forks_count":0,"subscribers_count":3,"default_branch":"main","last_synced_at":"2025-02-12T08:58:42.826Z","etag":null,"topics":["docker","docker-compose","dockerfile"],"latest_commit_sha":null,"homepage":"","language":"Makefile","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/devlights.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-10-18T02:19:50.000Z","updated_at":"2021-12-20T08:09:03.000Z","dependencies_parsed_at":"2022-09-04T15:32:50.769Z","dependency_job_id":null,"html_url":"https://github.com/devlights/try-docker","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/devlights%2Ftry-docker","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/devlights%2Ftry-docker/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/devlights%2Ftry-docker/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/devlights%2Ftry-docker/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/devlights","download_url":"https://codeload.github.com/devlights/try-docker/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247427012,"owners_count":20937214,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["docker","docker-compose","dockerfile"],"created_at":"2024-10-09T19:10:53.653Z","updated_at":"2025-04-06T03:13:40.559Z","avatar_url":"https://github.com/devlights.png","language":"Makefile","funding_links":[],"categories":[],"sub_categories":[],"readme":"# try-docker\nThis is a repository for learning Docker. (for myself)\n\n# Launch docker daemon in Gitpod\n\n基本、最初からDockerデーモンは起動しているので以下のコマンドは実施する必要はない。\n\n```sh\n$ sudo docker-up\n```\n\n- https://www.gitpod.io/blog/root-docker-and-vscode\n\n\n# WSL2\n\nWSL2が出るまでは、WindowsのHomeエディションではデスクトップ版のDockerが利用できなかった。\n\n2020年春頃のWindowsアップデートにて、WSL2がリリースされたため、現在はHomeエディションでもデスクトップ版Dockerが利用できるようになった。\n\n# メモ\n\nコンテナ操作の基本は、コマンドでの命令。\n\nコンテナを操作するコマンド文はすべて「docker」から始まる。\ndockerと書いてから、「何を」「どうする」「対象」などを記述して実行する。\n\ndockerコマンドに続けて書く「何を」「どうする」の部分を「コマンド」と呼ぶ。\nコマンドは「上位コマンド」と「副コマンド」で構成されている。\n\n上位コマンドの部分が「何を」、副コマンドの部分が「どうする」に該当する。\nまた、「対象」の部分には、コンテナ名やイメージ名などの具体的な名前が入る。\n\n##### 例\n\n```sh\n$ docker コマンド 対象\n```\n\n```sh\n$ docker image pull xxxxx\n$ docker container start xxxxx\n```\n\n```sh\n$ docker container run -d xxxxx                            # -d は「バックグラウンドで実行する」の意味\n$ docker container run --interactive --tty --detach xxxxx  # docker run -it -d xxxxx と同じ\n```\n\n歴史的経緯から、「start」や「run」のように ```container``` を付けなくても実行できるコマンドがある。\nDocker 1.13にて、コマンドの再編成が実施され、上位コマンドと副コマンドの組み合わせに統一された。\n旧形式の実行方法も現在のところ可能。\n\n##### 旧形式\n\n```sh\n$ docker run xxxxx\n```\n\n##### 新形式\n\n```sh\n$ docker container run xxxxx\n```\n\nヘルプを見たい場合は以下のようにする。\n\n```sh\n$ docker --help\n$ docker image --help\n$ docker container run --help \n```\n\n上記は、それぞれ出力されるヘルプの内容が異なる。\n\nインストールされているDockerの情報を調べたい場合は ```docker version``` とする。\n\n```sh\ngitpod /workspace/try-docker $ docker version\nClient: Docker Engine - Community\n Version:           20.10.8\n API version:       1.41\n Go version:        go1.16.6\n Git commit:        3967b7d\n Built:             Fri Jul 30 19:54:27 2021\n OS/Arch:           linux/amd64\n Context:           default\n Experimental:      true\n\nServer: Docker Engine - Community\n Engine:\n  Version:          20.10.8\n  API version:      1.41 (minimum version 1.12)\n  Go version:       go1.16.6\n  Git commit:       75249d8\n  Built:            Fri Jul 30 19:52:33 2021\n  OS/Arch:          linux/amd64\n  Experimental:     true\n containerd:\n  Version:          1.4.9\n  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3\n gitpod:\n  Version:          1.0.1\n  GitCommit:        v1.0.1-0-g4144b63\n docker-init:\n  Version:          0.19.0\n  GitCommit:        de40ad0\n```\n\n```docker run``` は、以下のコマンドの動作をひとまとめにしたもの。\n\n```sh\n$ docker image pull\n$ docker container create\n$ docker container start\n```\n\nホストOSの特定のディレクトリをマウントした状態で起動したい場合は以下のようにする。\n\n```sh\n$ docker run -it -v ${PWD}:/app -w container-working-directory --name container-name image-name\n```\n\n```sh\n$ docker run -it -v ${PWD}:/app -w /app --name mycontainer alpine:latest\n```\n\n```docker ps``` コマンドと ```docker container list``` は同じ。\n\n```sh\n$ docker ps [-a]\n$ docker container list [-a]\n```\n\n```docker ps``` が古い形式。\n\nコンテナIDやイメージIDを指定する際は、一意な部分のみを指定できれば良い。\n\nなので、例えば\n\n```sh\n$ docker image list -a\nREPOSITORY   TAG       IMAGE ID       CREATED       SIZE\nhttpd        latest    d54056386fbb   5 days ago    138MB\nalpine       latest    14119a10abf4   7 weeks ago   5.59MB\n```\n\nとなっていたら\n\n```sh\n$ docker image rm d5\n```\n\nコンテナを破棄するためには、停止する必要がある。コンテナは動いているものをいきなり削除できない。\n\n```sh\n$ docker container stop xxxxx\n$ docker container rm xxxxx\n```\n\nコンテナはデフォルトでは外から通信アクセスできない状態となっている。アクセスできるように設定するためには、コンテナ作成時に設定する必要がある。\n\n基本的に作成後に変更は出来ない。ポートを指定する場合は ```-p 8888:80``` のように指定する。前がホスト側のポート番号、後ろがコンテナ側のポート番号。\n\n```sh\n$ docker run -d --name apa001 -p 8888:80 httpd:latest\n```\n\ndockerコマンド実行時に環境変数を設定する場合は ```-e``` オプションを指定する。\n環境変数一つずつに ```-e``` が必要となる。例えば、３つ指定する場合は\n\n```sh\n-e XXX=XXX -e XXX=XXX -e XXX=XXX\n```\n\nとなる。\n\nコンテナを削除しても、イメージは残ったままとなる。イメージを削除するためには、そのイメージから作成したコンテナが全て削除されていないといけない。\n\nコンテナ同士を繋ぐ場合、ただ普通にコンテナを作っただけでは、コンテナは繋がらないので、仮想的なネットワークを作り、そこに両方のコンテナを所属させることで、コンテナ同士を繋げる。\n\n仮想的なネットワークを作るコマンドが ```docker network create``` となる。\n\n```sh\n$ docker network create xxx\n$ docker network rm xxx\n```\n\ndockerコマンド実行時にネットワークを設置する場合は ```--net``` オプションを指定する。\n\n# コンテナとホスト間でファイルをコピーする\n\nコピーは、コンテナからホスト、ホストからコンテナのどちらも可能。\n\n```docker container cp``` コマンドを使う\n\n## ホストからコンテナ\n\n```sh\n$ docker container cp ../README.md filecp001:/app\n```\n\n## コンテナからホスト\n\n```sh\n$ docker container cp filecp001:/app/README.md ./README2.md\n```\n\n# ボリュームのマウント\n\n実際にコンテナを使うのであれば、記憶領域のマウントが必須。なぜなら、そこにデータを置くから。\n\n記憶領域のマウント方法は2種類ある。\n\n- ボリュームマウント\n  - Dockerエンジンが管理している領域内にボリュームを作成し、ディスクとしてコンテナにマウントする。\n  - 名前だけで管理できるので手軽に扱える反面、ボリュームに対して直接操作しづらい。\n    - 仮で使いたい場合\n    - 滅多に触らないけど、消してはいけないファイル\n- バインドマウント\n  - Dockerをインストールしたパソコンの場所、つまり、Dockerエンジンが管理していない場所の既に存在するディレクトリをコンテナにマウントする。\n  - ディレクトリだけではなく、ファイル単位でもマウントできる。\n  - ディレクトリに対して直接ファイルを置いたり開いたりできるので、頻繁に触るファイルはここに置くべき。\n\nバインドマウントは、Dockerの管理外の好きな場所におけるので、普通のファイルと同じように扱えるのが売り。\n\nこの他にも「一時メモリ(tmpfs)マウント」というのもある。その名前の通り、メモリにマウントする方法。当然コンテナの再起動で消える。\n\nボリュームマウント、バインドマウントのどちらの方法でも、記憶領域のマウントは ```docker container run``` コマンドにオプションとして指定する。\n\n```sh\n$ docker container run -v ホストのパス:コンテナのパス\n$ docker container run --volume ホストのパス:コンテナのパス\n```\n\nマウントしたい場所が複数存在する場合は、```-v (--volume)``` オプションを複数回指定すれば良い。\n\n# コンテナのイメージ化\n\nコンテナを別の環境にコピーしたい場合などに利用するので、サーバエンジニアは必須の知識となる。\n\nイメージの作成方法には２つある。\n\n- すでにあるコンテナを ```docker container commit``` でイメージの書き出しをする方法\n- ```Dockerfile``` でイメージを作る方法\n\n## commit で書き出す方法\n\n```sh\n$ docker container commit commit001 try-docker/commit2:latest\n```\n\n## Dockerfileを使う方法\n\n```sh\n$ docker build -f Dockerfileのパス -t イメージ名:タグ 材料フォルダのパス\n```\n\n通常は以下のようになる。\n\n```sh\n$ docker build -f Dockerfile -t xxx:1.0 .\n```\n\nDockerfile の中で使う命令は以下のようなものとなる。\n\n- FROM\n  - 元にするイメージを指定する\n- ADD\n  - イメージにファイルやフォルダを追加する\n- COPY\n  - イメージにファイルやフォルダを追加する\n- RUN\n  - イメージをビルドするときにコマンドを実行する\n- CMD\n  - コンテナを起動するときに実行する既存のコマンドを指定する\n- ENTRYPOINT\n  - イメージを実行するときのコマンドを強要する\n- ONBUILD\n  - ビルド完了したときに任意の命令を実行する\n- EXPOSE\n  - 通信を想定するポートをイメージの利用者に伝える\n- VOLUME\n  - 永続データが保存される場所をイメージの利用者に伝える\n- ENV\n  - 環境変数を定義する\n- WORKDIR\n  - RUN, CMD, ENTRYPOINT, ADD, COPYの際の作業ディレクトリを指定する\n- SHELL\n  - ビルド時のシェルを指定する\n- LABEL\n  - 名前やバージョン番号、製作者情報などを設定する\n- USER\n  - RUN, CMD, ENTRYPOINTで指定するコマンドを実行するユーザやグループを設定する\n- ARG\n  - ```docker image build```する際に指定できる引数を宣言する\n- STOPSIGNAL\n  - ```docker container stop``` する際に、コンテナで実行しているプログラムに対して送信するシグナルを変更する\n- HEALTHCHECK\n  - コンテナの死活確認をするヘルスチェックの方法をカスタマイズする\n\n\n# イメージのSaveとLoad（持ち運び）\n\nコンテナはそのままでは移動・コピーが出来ない。一旦イメージにする必要がある。\n\nただし、イメージもそのままでは利用できないので、Dockerレジストリを経由させるか、 ```docker image save``` コマンドで tar ファイルにする。\n\nファイルからイメージとして取り込みたい場合は ```docker image load``` コマンドを利用する。\n\n```sh\n$ docker image save -o xxxx.tar イメージ名\n```\n\n```sh\n$ docker image load --input xxxx.tar\n```\n\n# コンテナの改造\n\n## シェルの起動\n\nコンテナは、何も指定せずに起動すると、当然シェルも動いていない状態となる。\n\nなので、bashなどのシェルを起動して命令を受け取ってもらうようにする必要がある。\n\n起動中のコンテナに対して、シェル起動して中に入るには ```docker container exec``` を使う。\n\n```sh\n$ docker container exec -it container-name /bin/bash\n```\n\nようにする。\n\n```docker container run``` に対して引数でシェルを指定することもできるが、その場合コンテナに入っているソフトウェアを動かす代わりに\nシェルを動かすことになる。なので、コンテナは作られているものの、ソフトウェアがスタートしていない状態となる。シェルでの操作が終わった後に\n改めて ```docker container start``` でスタートさせる必要が出てくる。\n\nなので、```docker container exec``` を使う。\n\n\n# プライベートレジストリ\n\n普通に ```docker image pull``` や ```docker container run``` を利用すると デフォルト では [DockerHub](https://hub.docker.com/) からイメージをダウンロードする。\n\nイメージの配布場所を ```Dockerレジストリ``` と言う。一般に公開されているか否かに関わらず、配布場所と言えばDockerレジストリと呼ぶ。\n\n[DockerHub](https://hub.docker.com/)は、Dockerレジストリのうち、Docker社の公式が運営しているもの。\n\n当然、プライベートなDockerレジストリも作成することができる。\n\n## レジストリとリポジトリ\n\nレジストリ（登記所）とリポジトリ（倉庫）は似ているが違う。\n\nレジストリは ```イメージの配布場所``` 。一方、リポジトリは、レジストリの中をさらに区切った単位。\n\n一つのレジストリの中にNのリポジトリが存在する。\n\n## アップロード方法\n\nイメージのアップロード先が [DockerHub](https://hub.docker.com/) であっても、プライベートなDockerレジストリであってもイメージにはタグをつける必要がある。\n\nタグ名は以下のような命名となる。\n\n```レジストリの場所/リポジトリ名:バージョン番号```\n\n例として以下のようになる\n\n#### localhost:5000 で公開されているレジストリで、priregというリポジトリ名で、バージョン番号が1.0\n\n```localhost:5000/prireg:1.0```\n\n(*) [DockerHub](https://hub.docker.com/) の場合は ```DockerHubのID/リポジトリ名:バージョン番号``` となる\n\nイメージにタグを付与するには ```docker image tag``` コマンドを使う\n\n```sh\n$ docker image tag 元のイメージ名 レジストリの場所/リポジトリ名:バージョン番号\n```\n\n```sh\n$ docker image tag try-docker/prireg:latest localhost:5000/prireg:1.0\n```\n\nイメージをアップするには ```docker image push``` コマンドを使う\n\n```sh\n$ docker image push レジストリの場所/リポジトリ名:バージョン番号\n```\n\n```sh\n$ docker image push localhost:5000/prireg:1.0\n```\n\n## プライベートレジストリを作る\n\nDockerでは、レジストリも一つのコンテナとして表現される。\n\nレジストリ用のイメージが提供されているので、以下のようにコンテナを起動すると、そのホストの中にプライベートレジストリが起動する。\n\n```sh\n$ docker container run --name reg001 -d -p 5000:5000 registry \n```\n\n# Docker Compose\n\nDockerでの構築作業に関わるコマンド文の内容を１つのテキストファイル（定義ファイル)(YAML) に書き込んで、一気に実行したり停止・破棄したりするのが ```Docker Compose``` 。\n\n実際にDockerで作業する場合は、dockerコマンドを手打ちで頑張ることはあまりなくて、このDocker Composeを使って作業することが多い。\n\nファイルの名前は通常 ```docker-compose.yml``` とする。\n\n起動は ```docker-compose -f 定義ファイル up オプション``` とする。\n\n停止は ```docker-compose -f 定義ファイル down オプション``` とする。\n\n定義ファイルには、コンテナやボリュームを「こういう設定で作りたい」という項目を書いておく。\n\nDockerfileと似ているが、Dockerfileはイメージを作るものなので、ネットワークやボリュームなどは作れない。\n\nKubernetesとも似ている感じがするが、KubernetesはDockerコンテナを管理するもので、Docker Composeはコンテナなどを作って消すだけで管理機能は持っていない。\n\nDocker Compose は、WindowsとMacの場合はDockerデスクトップ版に付属しているので追加のインストール作業は必要ない。\n\nLinuxの場合は Docker Compose と Python3 のインストールが必要となる。\n\nインストール方法は [Docker Composeのインストール](https://docs.docker.jp/compose/install.html#linux) を参照。\n\ndocker-composeのバージョンは以下で確認できる。\n\n```sh\n$ docker-compose version\ndocker-compose version 1.29.2, build 5becea4c\ndocker-py version: 5.0.0\nCPython version: 3.7.10\nOpenSSL version: OpenSSL 1.1.0l  10 Sep 2019\n```\n\ndocker-compose.yml の内容は例えば以下のようになる。\n\n```yaml\nversion: \"3\"\n\nservices:\n  httpd001:\n    build:\n      context: .\n      dockerfile: Dockerfile.apache\n    networks:\n      - net1\n    ports:\n      - 8085:80\n    restart: always\n  tomcat001:\n    build:\n      context: .\n      dockerfile: Dockerfile.tomcat\n    networks:\n      - net1\n    restart: always\n    depends_on:\n      - httpd001\nnetworks:\n  net1:\n\n```\n\n後は、docker-compose.yml が存在するディレクトリに移動して\n\n```sh\n$ docker-compose up -d\n```\n\nで起動して\n\n```sh\n$ docker-compose down\n```\n\nで停止となる。\n\n\n# Kubernetes\n\nKubernetesは複数の物理的マシンに複数のコンテナがあることが前提。\n\nDockerは、1代のブルリ的マシンで実行するイメージだが、Kubernetesは複数の物理的マシンがあることが前提。\n\nさらに、その1台の中に複数のコンテナがあるという状況で利用価値がある。\n\n複数のコンテナを1台ずつ作ったり、管理したりするのは大変なので、Kubernetesが肩代わりして管理してくれるイメージ。\n\nKubernetesは、このようなコンテナの作成や管理の煩雑さをうまくやってくれるツールで、Docker Composeのような定義ファイル（マニフェストファイル）を\nつくっておけば、それに従って対象の物理マシンにコンテナを作成して管理してくれる。\n\n## マスタノードとワーカーノード\n\nKubernetesは マスターノード と呼ばれるコントロールを司るノードと ワーカーノード と呼ばれる実際に動かすノードで構成される。\n\nマスターノードは、現場監督のようなもの。マスターノード上でコンテナは動かない。ワーカーノード上のコンテナを管理するのが仕事。\n\nなので、マスターノードにはDocker Engineもインストールしない。\n\nワーカーノードは、実際のサーバに当たる部分で、コンテナはここで動く。\n\nこのように、マスターノードとワーカーノードで構成されたKubernetesシステムの一群を クラスター と呼ぶ。\n\n\n## Kubernetes 動作に必要なもの\n\n- マスターノード\n  - Kubernetes 本体\n  - CNI (仮想ネットワークドライバ)\n    - flannel\n    - Clico\n    - AWS VPC CNI\n  - etcd\n- ワーカーノード\n  - Kubernetes 本体\n  - CNI\n  - Docker Engine\n\nまた、マスターノードを管理するために 管理者 のマシンには kubectl というものを入れる必要がある。\n\n\n## Kubernetes は、状態を維持する\n\nKubernetes では、あるべき姿（コンテナをN個、ボリュームをN個で構成）をYAML形式のマニフェストファイルに記載して動かす。\n\nDocker Composeは、オプションの指定によって手動でコンテナの数を返ることはできるが、監視はしていないので、作成時しか関与しない「作って終わり」のもの。\n\nKubernetesは、「その状態を維持」する。\n\nなので、なんらかの理由でコンテナが壊れた場合、Kubernetesが勝手に壊れたコンテナを削除して、新しく作り直したりしてくれる。（ちゃんと設定していれば）\n\n\n## 最低限知っておくべき用語\n\n- Pod\n  - コンテナとボリュームのセット\n  - Kubernetesが管理する最小単位\n- サービス\n  - Podへのアクセスを管理\n- デプロイメント\n  - Podのデプロイを管理\n\n同一構成のPodの塊を レプリカ (Replica) という。\n\n\n## 最低限知っておくべき事実\n\nKubernetesを「ちゃんと」使うには、しっかりとして大量の知識とネットワークに関する深い知識などが必要になる。\n\nさらに、Kubernetesは本来大規模なシステムが前提であり、マスターノードとワーカーノードは別々の物理的マシンにされているなど、簡単に手が出せるものではない。\n\nClusterIPの設定やその前に置くロードバランサなどはインフラ屋さんに頼まないといけない。\n\nなので、現実的に大企業に属しているなどじゃないと、イチから構築などはまずチャンスがない。\n\nほとんどの人はクラウドを利用してKubernetesに触れることになる。\n\n単に触ってみる程度であれば、Dockerデスクトップ版でお試しKubernetesがインストールできるので、それで触ってみるのがいいかもしれない。\n\nLinuxの場合はMinikubeをインストールして操作してみるという感じになる。\n\nWSL2環境のDebian/sidに Minikube をインストールしてみた感じ、以下のようになった。\n\n```sh\n$ cat /etc/os-release\ncat /etc/os-release\nPRETTY_NAME=\"Debian GNU/Linux bookworm/sid\"\nNAME=\"Debian GNU/Linux\"\nID=debian\nHOME_URL=\"https://www.debian.org/\"\nSUPPORT_URL=\"https://www.debian.org/support\"\nBUG_REPORT_URL=\"https://bugs.debian.org/\"\n\n\n\n$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb\nsudo dpkg -i minikube_latest_amd64.deb\n  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n100 22.2M  100 22.2M    0     0  21.9M      0  0:00:01  0:00:01 --:--:-- 21.9M\nSelecting previously unselected package minikube.\n(Reading database ... 39822 files and directories currently installed.)\nPreparing to unpack minikube_latest_amd64.deb ...\nUnpacking minikube (1.23.2-0) ...\nSetting up minikube (1.23.2-0) ...\n\n\n$ sudo dpkg -i minikube_latest_amd64.deb\n(Reading database ... 39823 files and directories currently installed.)\nPreparing to unpack minikube_latest_amd64.deb ...\nUnpacking minikube (1.23.2-0) over (1.23.2-0) ...\nSetting up minikube (1.23.2-0) ...\n\n\n$ minikube start --vm-driver=none\n😄  minikube v1.23.2 on Debian bookworm/sid\n✨  Using the none driver based on user configuration\n\n🤷  Exiting due to PROVIDER_NONE_NOT_FOUND: The 'none' provider was not found: exec: \"iptables\": executable file not found in $PATH\n💡  Suggestion: iptables must be installed\n📘  Documentation: https://minikube.sigs.k8s.io/docs/reference/drivers/none/\n```\n\nちなみに Gitpod 上ではエラーが出て Minikube が動作しなかった。\n\n```sh\n$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb\n$ sudo dpkg -i minikube_latest_amd64.deb\n$ sudo apt update \u0026\u0026 sudo apt install conntrack\n\n$ minikube start --vm-driver=none\n😄  minikube v1.23.2 on Ubuntu 20.04 (amd64)\n✨  Using the none driver based on user configuration\n👍  Starting control plane node minikube in cluster minikube\n🤹  Running on localhost (CPUs=16, Memory=64319MB, Disk=595282MB) ...\nℹ️  OS release is Ubuntu 20.04.2 LTS\n\n❌  Exiting due to RUNTIME_ENABLE: sudo systemctl daemon-reload: exit status 1\nstdout:\n\nstderr:\nSystem has not been booted with systemd as init system (PID 1). Can't operate.\nFailed to connect to bus: Host is down\n\n\n╭───────────────────────────────────────────────────────────────────────────────────────────╮\n│                                                                                           │\n│    😿  If the above advice does not help, please let us know:                             │\n│    👉  https://github.com/kubernetes/minikube/issues/new/choose                           │\n│                                                                                           │\n│    Please run `minikube logs --file=logs.txt` and attach logs.txt to the GitHub issue.    │\n│                                                                                           │\n╰───────────────────────────────────────────────────────────────────────────────────────────╯\n```\n\n## Windows上のDockerデスクトップでKubernetesを有効にして試してみた例\n\n#### デプロイメント\n\nファイル名は ```httpd001dep.yml``` とした\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: httpd001dep\nspec:\n  selector:\n    matchLabels:\n      app: httpd001kube\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: httpd001kube\n    spec:\n      containers:\n        - name: httpd001\n          image: httpd\n          ports:\n            - containerPort: 80\n```\n\n#### サービス\n\nファイル名は ```httpd001ser.yml``` とした\n\n```yaml\napiVersion: v1\nkind: Service\nmetadata:\n  name: httpd001ser\nspec:\n  type: NodePort\n  ports:\n  - port: 8099\n    targetPort: 80\n    protocol: TCP\n    nodePort: 30080\n  selector:\n    app: httpd001kube\n```\n\n#### 実行\n\nデプロイメントを適用する\n\n```sh\n$ kubectl apply -f ./httpd001dep.yml\ndeployment.apps/httpd001dep created\n```\n\nPodの状況を見てみる。\n\n```sh\n$ kubectl get pods\nNAME                          READY   STATUS    RESTARTS   AGE\nhttpd001dep-945d9f6dd-6q997   1/1     Running   0          14s\n```\n\nレプリカの数を１にしているので、起動しているコンテナは１つ。\n\n次にレプリカの数を３に変更して再度適用。\n\n```sh\n$ kubectl apply -f ./httpd001dep.yml\ndeployment.apps/httpd001dep created\n```\n\n```sh\n$ kubectl get pods\nNAME                          READY   STATUS              RESTARTS   AGE\nhttpd001dep-945d9f6dd-2h6dz   0/1     ContainerCreating   0          1s\nhttpd001dep-945d9f6dd-6q997   1/1     Running             0          22s\nhttpd001dep-945d9f6dd-sz6gg   0/1     ContainerCreating   0          1s\n```\n\nコンテナの数が自動的に調整された。\n\n\nサービスを適用する\n\n```sh\n$ kubectl apply -f ./httpd001ser.yml\nservice/httpd001ser created\n```\n\nサービスの状況を確認\n\n```sh\n$ kubectl get services\nNAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE\nhttpd001ser   NodePort    10.107.153.247   \u003cnone\u003e        8099:30080/TCP   6s\nkubernetes    ClusterIP   10.96.0.1        \u003cnone\u003e        443/TCP          65m\n```\n\nホストOS側の30080番ポートに httpd が接続されているので、ブラウザで localhost:30080 を確認するとApacheの ```It Works!!``` が表示される。\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdevlights%2Ftry-docker","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdevlights%2Ftry-docker","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdevlights%2Ftry-docker/lists"}