Docker Composeツールは、コンテナーを操作してきた多くの人々にとって価値があります。ドキュメントによると、DockerComposeはそれ自体を次のように説明しています。
...マルチコンテナアプリケーションを定義および実行するためのツール。 Composeでは、YAMLファイルを使用してアプリケーションのサービスを構成します。次に、1つのコマンドで、構成からすべてのサービスを作成して開始します。
Docker Composeの課題の1つは、YAMLファイル形式がDockerエンジンでのみ機能することです。ローカルレプリケーションのために他のDockerユーザーに提供することはできますが、他のコンテナーランタイムで使用することはできません。つまり、今まで。
[関連チュートリアル:PodmanとDockerComposeの使用]
Podman 3.0では、DockerComposeはPodmanバックエンドで動作します
DockerComposeに基づくコンテナーをKubernetesYAMLファイルに簡単に変換することで、Podmanの真の力が発揮されます。 Docker Composeと同様に、PodmanはKubernetesYAMLファイルを使用してコンテナーをローカルに複製できます。さらに重要なことに、これによりPodmanは、Kubernetes/OpenShiftやminikubeなどの多くのプラットフォームで実行できるオーケストレーションされたポッドとサービスを利用できます。
この記事では、2つのコンテナーを使用してWordPressを実行する単純なComposeファイルから開始するプロセスについて説明します。このComposeファイルのソースは、Dockerのawesome-composeリポジトリのGitHubで公開されています。このファイルをPodmanで正常に使用すると、ブラウザにWordPressの初期設定画面が表示されます。
注 :この記事の執筆時点では、docker-compose
のみをサポートしています。 コマンドはルート的に実行されます。
Podmanのシステムサービスを開始する
Composeを使用するための最初のステップは、必要なすべてのパッケージがインストールされていることを確認してから、systemd
を使用してPodman(3.0以降)システムサービスをセットアップすることです。 。パッケージをインストールした後、Podman systemd
を有効にして起動します 次のコマンドを使用したソケット起動サービス:
$ sudo systemctl enable --now podman.socket
pingエンドポイントにアクセスして、サービスが実行されていることを確認します。このステップは、先に進む前に成功する必要があります。
$ sudo curl -H "Content-Type: application/json" --unix-socket /var/run/docker.sock http://localhost/_ping
OK
これで、RESTful APIが機能していることを確認して、自信を持ってComposeを実行できます。
作成の実行
前述のように、この例では2つのコンテナーで構成されるComposeファイルを実行して、WordPressセッションを起動します。 1つのコンテナはApacheWebサービスを実行し、もう1つのコンテナはデータをMySQLデータベースに格納します。 2つのコンテナーは、このComposeインスタンス専用のネットワークを介してTCP/IPを介して通信します。コンテナを表示するには、docker-compose up
を実行します 。
$ sudo docker-compose up -d
Creating network "wordpress-mysql_default" with the default driver
Creating volume "wordpress-mysql_db_data" with default driver
Pulling db (mysql:8.0.19)...
0c27e8e5fcfab7805cfed996b55e5e98f43fd7ee76e1516f20cba139c6a299c5: pulling image () from docker.io/library/mysql:8.0.19
Pulling wordpress (wordpress:latest)...
0d35c2300ec845fda141ba012f7c6dccde8f0ae106b8f4bb0fcfced69380f851: pulling image () from docker.io/library/wordpress:latest
Creating wordpress-mysql_db_1 ... done
Creating wordpress-mysql_wordpress_1 ... done
podman ps
を使用します 2つのコンテナーが作成され、現在実行されていることを確認するコマンド。 Dockerデーモンは必要ありませんでした。
$ sudo podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a089a40bb9ae docker.io/library/mysql:8.0.19 --default-authent... 15 seconds ago Up 15 seconds ago kind_hermann
510c028c273f docker.io/library/wordpress:latest apache2-foregroun... 15 seconds ago Up 15 seconds ago 0.0.0.0:80->80/tcp competent_kilby
$
WordPressがローカルで実行されていることを確認する
WordPressを実行するための手順は、WordPressが正しく機能しており、ローカルホストとポート80を使用してアクセスできることを示しています。
KubernetesYAMLを作成する
ローカルマシンでWordPressのインスタンスが動作している状態で、Kubernetesプラットフォームでこれらのコンテナを複製するプロセスを開始します。 Podmanは、実行中のコンテナからKubernetesベースのYAMLを生成できます。
[次もお読みください:ローカルマシンからKubernetesの学習を開始してください]
1つのポッドまたは複数のポッド?
Kubernetes環境で使用するYAMLを作成するには、2つのアプローチがあります。サービスを使用して1つのポッドに2つのコンテナーを配置するか、それぞれに1つのコンテナーを含む2つのポッドと、Apacheフロントエンドを公開するサービスを作成します。どのアプローチが最適かを判断するには、試行錯誤が必要になる場合があります。
使用するアプローチを決定する可能性のある考慮事項の1つは、コンテナーまたはポッドがどのように通信するかです。 Composeがこれらのコンテナーを作成すると、一連の手順を実行して、2つのコンテナーがDNS名を使用して相互に通信できるようにしました。実際、Composeは、コンテナを名前で解決するときにDNS名として認識されるコンテナにエイリアスを設定します。コンテナを同じポッド内に配置することで、コンテナはネットワーク名前空間を共有するため、コンテナ間で名前解決を行う必要がなくなります。したがって、 localhostを使用するだけで済みます。 お互いにコミュニケーションをとる。
コンテナを異なるKubernetesポッドに配置すると柔軟性が向上しますが、コンテナは他のメカニズムを使用して相互に通信する必要があります。
YAMLを生成する
Kubernetes YAMLの作成を開始するには、コンテナ名またはIDを知っている必要があります。 PodmanがKubernetesのサービス記述を生成するかどうかを決定します。この場合、Apacheフロントエンドを公開して、ブラウザーを使用してWordPressと対話できるようにします。 podman generate kube
を使用します YAMLファイルを作成するコマンド。
$ sudo podman generate kube -s -f wordpress.yaml a089a40bb9ae 510c028c273f
-s
前のコマンドは、Podmanがこのポッドのサービスを生成することを意味します。 -f
オプションを使用すると、生成されたYAMLをファイルに保存できます。それ以外の場合、出力は stdoutに送信されます 、ファイルにリダイレクトできます。
$ cat wordpress.yaml
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-3.0.0-dev
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2020-12-03T22:30:07Z"
labels:
app: kindhermann
name: kindhermann
spec:
containers:
- command:
- docker-entrypoint.sh
- --default-authentication-plugin=mysql_native_password
env:
- name: PATH
value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
...
workingDir: /
- command:
- docker-entrypoint.sh
- apache2-foreground
env:
- name: PATH
value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
...
- name: WORDPRESS_DB_HOST
value: kindhermann
- name: WORDPRESS_DB_PASSWORD
value: db
- name: APACHE_ENVVARS
value: /etc/apache2/envvars
...
image: docker.io/library/wordpress:latest
name: competentkilby
ports:
- containerPort: 80
hostPort: 80
protocol: TCP
resources: {}
securityContext:
allowPrivilegeEscalation: true
capabilities:
drop:
- CAP_MKNOD
- CAP_NET_RAW
privileged: false
readOnlyRootFilesystem: false
seLinuxOptions: {}
workingDir: /var/www/html
status: {}
---
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2020-12-03T22:30:07Z"
labels:
app: kindhermann
name: kindhermann
spec:
ports:
- name: "80"
nodePort: 30579
port: 80
protocol: TCP
targetPort: 0
selector:
app: kindhermann
type: NodePort
status:
loadBalancer: {}
ApacheコンテナがMySQLコンテナと通信するために、Composeファイルの作成者は、 WORDPRESS_DB_HOSTという名前の環境変数を使用することを選択しました。 MySQLコンテナのホスト名を示します。これをKubernetes環境で実行する前に、 WORDPRESS_DB_HOSTの値を変更してください MySQLコンテナ名( kindhermann この例では)または127.0.0.1(同じポッド内のコンテナーはローカルホストを介して相互に通信できます)。
...
- name: WORDPRESS_DB_HOST
value: kindhermann OR 127.0.0.1
---
サイドバー:
Composeがビルドを実行するとき
多くの作成例では、作成者はコンテナイメージを作成することを選択します。これは通常、追加のパッケージが必要であるか、イメージである程度のカスタマイズを実行する必要があるためです。これが発生すると、Podmanの画像ストアに追加の新しい画像が追加されます。出力されたKubernetesYAMLを実行することを選択すると、ローカルストアにのみ存在するコンテナイメージを参照するため、失敗する可能性があります。
これを修正するには、podman push
を使用します これらの新しいイメージをquay.ioなどのグローバルレジストリまたはKubernetes固有のレジストリに移動して、Kubernetesがこれらのイメージをプルできるようにします。結果のYAMLファイルの画像名がプッシュされた画像と同じであることを確認してください。
Kubernetes
この例を進めてKubernetes環境に適用する次のステップでは、minikubeとOpenShiftの両方でこの例を実行する方法を示します。 YAMLには、ポッドが別のKubernetes環境で実行されるのを妨げる特定のものはないため、理論的には他のKubernetesフレーバーで動作するはずです。
この記事は、minikubeおよび/またはOpenShift環境の存在を前提としています。 minikubeまたはOpenShiftKubernetes環境のセットアップをドキュメント化することはこの記事の範囲外です。
ミニクベ
minikubeにデプロイするための最初のステップは、ポッドを作成することです。
$ minikube kubectl -- create -f wordpress.yaml
pod/kindhermann created
service/kindhermann created
数秒待ってから、ポッドとコンテナのステータスを確認してください。速度とネットワーク帯域幅によっては、ポッドがすでに使用可能になっている場合があります。 kubectl get pods
を使用してポッドのステータスを確認します 。
$ minikube kubectl -- get pods
NAME READY STATUS RESTARTS AGE
kindhermann 2/2 Running 0 28
両方のコンテナーの準備ができたので、WordPressセッションの可用性をテストします。まず、kubectl
を使用してKubernetesのポッドのIPアドレスを取得します 。
$ minikube kubectl -- describe pods | grep Node:
Node: minikube/192.168.39.7
選択したブラウザでポッドのIPアドレスを指定すると、WordPressのセットアップ画面が表示されます。
OpenShift
この記事では、OpenShiftクラスターがGCPで実行されています。
生成されたwordpress.yaml
を使用します ポッドとサービスを作成します。バニラKubernetes環境を使用している場合は、oc
を置き換えます kubectl
を使用 次のコマンドで。
$ oc create -f wordpress.yaml
pod/kindhermann created
service/kindhermann created
ポッドとサービスが起動するまで数秒待ちます。 キンダーマン ポッドは実行中です 両方のコンテナが稼働している状態。 キンダーマン クラスターIPが割り当てられたサービスも利用できます。
$ oc get pods
NAME READY STATUS RESTARTS AGE
kindhermann 2/2 Running 0 39s
$ oc get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kindhermann NodePort 172.30.103.100 <none> 80:30579/TCP 45s
Kubernetes ClusterIP 172.30.0.1 <none> 443/TCP 44m
openshift ExternalName <none> Kubernetes.default.svc.cluster.local <none> 36m
コンソールでポッドとサービスを表示します。
クラスタの外部からサービスにアクセスするには、サービスを公開します。これにより、ルートが作成されます。
$ oc expose svc/kindhermann
route.route.openshift.io/kindhermann exposed
$ oc/kubectl get routes
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
kindhermann kindhermann-default.apps.ci-ln-d3gw292-f76d1.origin-ci-int-gce.dev.openshift.com kindhermann 80 None
サービスを公開すると、上記のホスト/ポートルートが作成され、そのエンドポイントにアクセスします。 OpenShiftまたはKubernetesクラスターで実行されているWordPressアプリケーションのセットアップページを表示します。
コンソールでルートを調べ、そこからエンドポイントに直接アクセスします。
[この無料の電子書籍を入手する:ダミーのKubernetesクラスターを管理する。 ]
まとめ
ご覧のとおり、Podman 3.0を使用すると、DockerCompose環境からKubernetesにワークロード構成を簡単に移動できます。 Podmanは、アプリケーションの開発中にDocker Composeの柔軟性を提供するだけでなく、アプリケーションが大規模なリーグに対応できるようになったときにKubernetesへの移行を容易にします。これはすべて、podman generate kube
を使用して行われます。 指図。 3つの簡単なステップで試してみてください。