とことんDevOps | 日本仮想化技術が提供するDevOps技術情報メディア

DevOpsに関連する技術情報を幅広く提供していきます。

日本仮想化技術がお届けするとことんDevOpsでは、DevOpsに関する技術情報や、日々のDevOps業務の中での検証結果など、DevOpsのお役立ち情報をお届けします。
主なテーマ: DevOps、CI/CD、アジャイル開発、コンテナ開発など

開催予定の勉強会

各種SNSのフォローもよろしくお願いいたします。

Rancher DesktopではじめるDocker/Kubernetes入門

Rancher Desktopはデスクトップ上でKubernetesとコンテナの管理を行うことができるツールです。containerdやDockerを使ってコンテナーイメージのビルド、プッシュ、ダウンロード、実行できます。

K3sを使ってKubernetesクラスターの実行もデスクトップ上で可能になっています。

Visual Studio CodeのRemote DevelopmentやDocker拡張機能などの導入によって、Rancher Desktopを使ってコンテナベースでアプリケーション開発も可能になっています。

今回はRancher Desktopを使って、DockerとKubernetesに入門してみましょう。

コンテナーとはなにか

コンテナーはアプリケーションを実行するプラットフォーム技術の一つで、アプリケーションをコンテナで実行します。コンテナー技術は自動化といった分野と相性が良く、DevOps界隈やインフラ界隈などで注目されている技術です。

仮想マシンでアプリケーションを実行するのと比べて、仮想マシンのハイパーバイザー層といったようなオーバーヘッドが少ないため、仮想マシンよりも高速にアプリケーション実行が可能になります。コンテナー技術はイメージベースのプラットフォームであり、コンテナー環境をセットアップすればそれがラップトップであろうが、専用のベアメタルサーバーだろうが、クラウド上のインスタンスであろうが、どこでも同じようにアプリケーションを実行できる可搬性を備えています。

Dockerとはなにか

Dockerは前述のようなコンテナーをLinux上で実行するための機能を提供するソフトウェアの一つです。Dockerは、コンテナと呼ばれるホストと緩やかに分離された環境でアプリケーションをパッケージ化して実行する機能を提供します。Linuxカーネルの分離とセキュリティ機能を利用することで特定のホストで多数のコンテナーを素早く、同時に実行できます。

コンテナは軽量かつ、アプリケーションの実行に必要なものがコンテナーにすべて含まれているため、ホストに現在インストールされているソフトウェアやライブラリー、プログラミング環境などに依存することなく、コンテナーでアプリケーションを実行できます。

コンテナは簡単に他の人と共有することもでき、共有相手全員が同じ方法を用いて手元の環境で同じように動作する環境を再現できます。

Linux以外でDockerを利用する

これまで説明したように、Dockerを利用するにはLinuxが必要でした。 Linux以外でDockerを利用するには仮想マシンソフトウェアなどで仮想マシンを作成してLinuxを実行し、その中でDockerを動かす方法があります。

設定次第ではこのVM内のDockerを、手元のWindowsやmacOSにインストールしたDocker CLIからネイティブにDockerが動いているように操作することも可能ですが、設定はちょっと大変です。

WindowsやmacOSで簡単にDockerを動かすことができるようにするために提供されているソフトウェアがDocker Desktopです。macOSの場合はQEMU、Windowsの場合はHyper-VもしくはLinux 用 Windows サブシステム(WSL) 2ベースでDockerが動いています。

Linux以外でDockerを利用するためのツールとしては、これまでDocker Desktopが事実上の標準として使われていました。しかし、昨年2021年8月にDocker社がDocker Desktopの利用規約を方針変更し、従業員250人、年間収益1,000万ドルを超える企業での利用を商用利用と判断するように変更しました。

なお、先程の規模未満での利用、個人使用、教育、および非営利のオープンソースプロジェクトでは無料のままです。しかしこの発表を期に、Docker Desktopから他のソリューションへ切り替えを検討するユーザーが増えました。

いくつかある代替ソフトウェアの一つがRancher Desktopです。

rancherdesktop.io

Rancher Desktopの特徴

Rancher Desktopは冒頭で説明したように、デスクトップ上でKubernetesとコンテナの管理を行うことができるツールです。ランタイムとしてDockerを使うように設定変更すれば、これまでのようにWindowsやmacOS上でDockerを利用できますし、特定のバージョンのKubernetesを素早くローカル上で稼働させて、コンテナベースのアプリケーション開発やテスト、実行を可能とします。

次のような特徴があります。

  • Windows/Mac/Linuxに対応
  • すべてOSSで開発
  • 内部コンポーネントもOSSで構成されている
  • 無料で使える
  • ContainerdもしくはDockerから選べる
  • 軽量K3sを使ったKubernetesクラスタの稼働が可能

Rancher Desktopの構成

Rancher DesktopはmacOSとLinuxではQEMU上でコンポーネントが動作し、Windows版はWSL v2上で動作します。 これらを各種コマンドラインツールやGUIツールを使って管理します。必要なコマンドラインツールはRancher Desktopに同梱されるため、別途導入する必要はありません。

Rancher Desktopのインストール

システム要件は導入するバージョンで変わってくるため、以下をご覧ください。

ざっくりと説明すると、CPU 4コア、メモリー8GB以上のマシンでの利用をおすすめします。これ以下の環境でも設定を調整すると動作する可能性はありますが、アプリケーションの実行は厳しいかと思います。

Rancher DesktopとProxy

プロキシ利用が前提な環境(特に企業や学校での利用)では、追加で「Proxy環境下でRancher Desktopを使うための設定」が必要な場合があります。 OSや選択するランタイムによって設定方法が違うようなので、ご注意ください。

Proxyの設定をしても正常に動作しない場合はSlackで質問を投げるか、GitHubに類似するIssueがないか確認してからIssueを上げると良いかなと思います。参考までに見つけたブログ記事をご紹介します。

Rancher Desktopの起動

インストール後、はじめて起動すると管理権限でのアクセスが必要といったようなメッセージが出ますので、管理ユーザーで認証をしてください。認証が通るとRancher Desktopがシステムコンテナを実行して、そのクライアントでDocker(もしくはcontainerd)やKubernetesが利用できるように設定されます。

ここから先は、コマンドを使ってDockerを利用します。macOSやLinuxでは端末(ターミナル)、Windowsの場合はWindows ターミナルもしくはPowerShell、コマンド プロンプトなどを使って操作してください。 以降、これらのことを端末と呼びます。ここからは端末でコマンド入力を中心に、Dockerを操作していきます。

Dockerイメージのダウンロード

Rancher Desktopの起動が終わったら、端末を起動してまずdocker infoと入力します。Serverとクライアントの情報が出力されたら、Dockerの準備はできています。次のように表示される場合は、まだDockerのサーバー側の準備ができていません。

% docker info     
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.2)
  compose: Docker Compose (Docker Inc., v2.6.1)

Server:
ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
errors pretty printing info

準備ができたらまずはイメージを検索してみましょう。Dockerはアプリケーションを実行するためのプラットフォームです。アプリケーションを実行するための環境を展開するためには適切なイメージを利用する必要があります。

例えば、アプリケーションがPHPで書かれているならPHPのオフィシャルイメージが適切ですし、Pythonで書かれているならPythonのイメージが適切です。オフィシャルイメージにはDebianベースのイメージと、Alpine Linuxベースのイメージが提供されている場合があります。イメージサイズはAlpine Linuxベースのイメージのほうが小さくなる傾向があります。ただし、Libcの互換性の問題から、アプリケーションの実行速度に影響があったり思ったように動作しない場合があるため、手放しで喜んでAlpine Linuxベースのイメージを使えばよいというわけではありません。

Dockerベースのイメージの場合、標準のイメージとイメージの名前に-slimがつくイメージが存在する場合があります。アプリケーションの実行に不要なものを削ぎ落としているイメージであり、slimバージョンのほうがイメージサイズは小さくなります。

DockerはコンテナでOSを動かすのが目的ではないため、できる限りイメージサイズの小さいイメージを選ぶと、後述のイメージをベースとしたカスタムイメージのビルドに要する時間も短縮できます。

% docker search debian
NAME                                  DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
ubuntu                                Ubuntu is a Debian-based Linux operating sys…   14692     [OK]       
debian                                Debian is a Linux distribution that's compos…   4393      [OK]       
neurodebian                           NeuroDebian provides neuroscience research s…   92        [OK]       
bitnami/debian-base-buildpack         Debian base compilation image                   2                    [OK]
treehouses/debian                                                                     2                    
ustclug/debian                        Official Debian Image with USTC Mirror          1                    
osrf/debian_armhf                     Debian Armhf Base Images                        1      
...

途中で省略しましたが、複数のイメージが見つかります。docker searchでは様々なユーザーが作ったイメージが候補として見つかることがあります。コンテナイメージはセキュリティのことを考えると、オフィシャルのイメージをベースに動かしたいアプリケーションを取り込んだイメージをビルドして利用するのがおすすめの運用になりますので、次のようにオプションを指定してみてください。

先程よりもイメージの数を絞れたと思います。これらはすべてオフィシャルのイメージです。「debian」イメージの検索にUbuntuが出てくるのは、UbuntuがDebianベースのLinuxだからです。

% docker search debian --filter is-official=true
NAME          DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
ubuntu        Ubuntu is a Debian-based Linux operating sys…   14692     [OK]       
debian        Debian is a Linux distribution that's compos…   4393      [OK]       
neurodebian   NeuroDebian provides neuroscience research s…   92        [OK]     

さて、いよいよイメージのダウンロードをするわけですが、ここでも注意するポイントがあります。それはイメージのタグを指定するということです。

イメージのタグではOSイメージのメジャーバージョンやマイナーバージョン、ビルド違いのイメージなどのタグが用意されています(前述の-slimも同様です)。イメージのタグを指定せずに次のように実行した場合、最新のバージョンのイメージが手元にキャッシュされます。

% docker image pull debian

「latest = 最新だから良いのでは?」と思いがちですが、何度も説明しているようにDockerはアプリケーションを実行するためのプラットフォームです。目的のアプリケーションが動かなければだめなわけです。この記事を書いた時点では「latest = Debian 11 bullseye」を指していますが、数年後には別のバージョンに差し替わっているかもしれません。OS自体やライブラリーのバージョンが変化することで、アプリケーションが想定通り動かなくなるかもしれません。一般的にはタグを使ってイメージのディストリビューションのバージョンを指定するのが適切です。

% docker image pull debian:bullseye-slim

Dockerのデフォルト設定ではDocker Hubのイメージを検索対象とします。ランタイムによっては他のレジストリサーバーが設定されている場合があります。イメージタグはブラウザーで次にアクセスして検索すると確認できます。

もしくは、端末でつぎのように実行すると、目的のイメージにあるタグを確認できます。

% PK_NAME=debian
% curl -s https://registry.hub.docker.com/v1/repositories/${PK_NAME}/tags | sed "s/,/\n/g" | grep name | cut -d '"' -f 4 

全てのタグが表示されるので、さらにgrepを使って絞り込むと良いでしょう。イメージによってはバージョンのほかコードネームでも検索できる場合があるので、Debian 11を示すbullseyeを指定するにはつぎのように実行します。

% curl -s https://registry.hub.docker.com/v1/repositories/${PK_NAME}/tags | sed "s/,/\n/g" | grep name | cut -d '"' -f 4 | grep "bullseye"
bullseye
bullseye-20190708
bullseye-20190708-slim
bullseye-20190812
bullseye-20190812-slim
...
bullseye-20220711
bullseye-20220711-slim
bullseye-20220801
bullseye-20220801-slim
bullseye-backports
bullseye-slim

よりアプリケーションの動作確認したイメージを明確にするなら、日付つきのイメージを使うと良いかもしれません。ちょっと試すだけであれば、Stableのslimバージョン(bullseye-slim)を選択しておけば間違いはないでしょう。 Debianのリリースバージョンとコードネームについてはつぎで確認できます。現在の最新安定版は「Debian 11 bullseye」です。その前の安定版は「Debian 10 buster」です。

アプリケーションを実行するために利用するコンテナイメージは、脆弱性やバグの修正を反映させるために適切なタイミングで新しいものに切り替える必要があります。

イメージによってはデイリービルドが存在しないイメージもあります。その場合は、より新しいイメージを選んでおけばよいでしょう。

Docker Hub以外のイメージレジストリーからコンテナイメージを取得(Pull)したい場合は、それらの配布ページに書かれているようにイメージ名の前にURLを追加すれば、Docker Hub以外から目的のイメージを取得できます。デフォルト設定の場合、以下の2つのコマンドは同じレジストリーからイメージを取得します。

% docker image pull debian:bullseye-slim
% docker image pull dockerio/debian:bullseye-slim

しかし、イメージの取得元を明確にするという点で言えば、2つ目のように実行する方が適切です。

Dockerイメージを確認

クライアント上にあるイメージのキャッシュの一覧を表示するには、つぎのように実行します。Rancher Desktopの場合はシステムコンテナイメージも表示されます。

% docker image ls               
REPOSITORY                         TAG                      IMAGE ID       CREATED          SIZE
debian                             bullseye-20220801-slim   e12dd81eada0   45 minutes ago   74.3MB
debian                             bullseye-slim            e12dd81eada0   45 minutes ago   74.3MB
debian                             bullseye                 585393df054a   45 minutes ago   118MB
nginx                              latest                   fd2d3e51789e   13 days ago      135MB
registry                           2                        45a1317536d5   13 days ago      22.5MB
rancher/klipper-helm               v0.7.3-build20220613     b524fed05410   7 weeks ago      228MB
...

Dockerコンテナの実行

ダウンロードしたイメージを使って、コンテナを実行してみましょう。 次のように実行します。

% docker container run -it debian:bullseye-slim  bash 

-iはインタラクティブモード、つまり対話型で開くかの指定です。デフォルトはfalseに設定されています。 -tはTTYを開くかどうかの指定です。これもデフォルトはfalseに設定されています。

今回はコンテナを実行してコンテナのシェルに入りたいので、それぞれ指定しています。 実行するとすぐコンテナのシェルに接続できるはずです。

% docker container run -it debian:bullseye-slim  bash 
root@5b678bf8688e:/# 
root@5b678bf8688e:/# cat /etc/debian_version 
11.4

もう一つ端末を開いて、次のコマンドを実行してみてください。すると、実行中のコンテナ一覧が表示されます。-aオプションを指定すると、クライアントに存在する作成済みコンテナが実行中の有無関わらずにすべて表示されます。

% docker container ls -a

CONTAINER ID   IMAGE                  COMMAND                  CREATED         STATUS                      PORTS                                       NAMES
5b678bf8688e   debian:bullseye-slim   "bash"                   2 minutes ago   Up 2 minutes                                                            angry_kilby
...
695a5bf6e09c   k8s.gcr.io/pause:3.6   "/pause"                 25 hours ago    Exited (0) 22 hours ago                                                 k8s_POD_svclb-traefik-0fc9ccce-48bl9_kube-system_f927800a-af25-4535-a75d-98c1939a1938_2
e5db09983b06   registry:2             "/entrypoint.sh /etc…"   6 days ago      Up 2 hours                  0.0.0.0:5000->5000/tcp, :::5000->5000/tcp   registry

コンテナ一つ一つには一意のIDと名前が割り当てられます。IMAGE列にはコンテナの作成に使われたイメージが、 COMMANDにはコンテナ実行時に実行したコマンドが、CREATEDにはコンテナ作成からどれくらいの時間が経過したか、STATUSは現在のコンテナの状況、PORTSにはコンテナを実行したときに 指定したポートが、NAMEにはコンテナの名前が表示されます。コンテナ名を指定せずにコンテナを実行した場合は、ランダムな名前がつけられます。

コンテナのシェルから抜けるには「logout」ではなく「exit」と入力します。

% docker container run -it debian:bullseye-slim  bash 
root@5b678bf8688e:/# logout
bash: logout: not login shell: use `exit'
root@5b678bf8688e:/# exit
exit
% 

Dockerコンテナの実行(応用編)

名前を指定してコンテナを作成

コンテナを実行する際に名前を指定しなかった場合はランダムな名前が適当に振られます。 コンテナに任意の名前をつけて実行することも可能です。

docker container run --name=名前 イメージ名 コマンド 

実行例

% docker container run --name=hoge  -it debian:bullseye-slim  bash

% docker container ls | grep debian:bullseye-slim
e5b72e529045   debian:bullseye-slim   "bash"       5 seconds ago   Up 4 seconds      ecstatic_villani  #ランダム名
ac68d94b777f   debian:bullseye-slim   "bash"        4 minutes ago   Up 4 minutes        hoge                  #名前を指定

筆者的には名前を指定したほうが好みです。理由としては、コンテナの削除をするときにわざわざ名前の確認をする必要がなくなるからです。

シェルからコマンドを実行

次のように実行すると、コンテナ内で指定したコマンドを実行してその結果を標準出力します。 シェルに入って実行するほどのことでない場合はこの方法を使います。

docker container run イメージ名 /bin/bash -c "コマンド"

実行例

% docker container run -it debian:bullseye-slim /bin/bash -c "cat /etc/debian_version"
11.4
%

Debianの場合、ファイル /etc/debian_versionには現在のDebianのバージョンが書かれています。 これを実行した結果、コンテナの中のDebianのバージョンがわかったわけです。

実際の用途としては、APIサーバーをコンテナで実行してその結果を出力するみたいなときに使うようなときに使うのかなと思います。

コンテナの削除

コンテナの場合、処理が終わったら多くの場合コンテナを終了するのがほとんどです(後述の-dオプションを指定した場合は異なる)。 不要なコンテナは消してしまいましょう。

コンテナ名がわかっている場合は次のように実行すると、コンテナを削除できます。削除するコンテナは停止されている必要があります。 停止されていない場合はdocker container stopでコンテナを停止、コンテナ名がわからない場合はdocker container lsで確認してください。

削除前であれば、停止したコンテナは再開できます。

% docker container ls
CONTAINER ID   IMAGE                  COMMAND                  CREATED             STATUS             PORTS                                       NAMES
e5b72e529045   debian:bullseye-slim   "bash"                   About an hour ago   Up About an hour                                               ecstatic_villani
ac68d94b777f   debian:bullseye-slim   "bash"                   2 hours ago         Up 2 hours                                                     hoge
...
% docker container stop ecstatic_villani hoge
(コンテナを停止)
% docker container rm ecstatic_villani hoge
(コンテナを削除)

なお、不要なコンテナが多数あって、全部指定するのが面倒であれば「停止済みのコンテナーをすべて削除」することもできます。 つぎのように実行してください。

% docker container rm $(docker container ls --filter status=exited -q)

Dockerとイメージ作成

Dockerはイメージベースでアプリケーションの実行環境(OSとライブラリー)をデプロイするものです。 イメージはコンテナレジストリで配布されています。コンテナレジストリはDocker HubやQuay.ioなどがあります(その他にも色々ありランタイムにデフォルト設定されています)。

ベースイメージに動かしたいアプリケーションを取り込み、独自のカスタムイメージを作って使うのが基本の利用スタイルになっています。

イメージを作る場合に守りたい「原則」は例えば次のようなものです。

  • できる限り余計なものは入れない
  • レイヤーという概念に注意する
  • root権限が不要であればユーザー権限でアプリを実行する

レイヤーについて詳しくは、About storage driversをご覧ください。 とりあえず覚えておくことは、「DockerコンテナーやDockerfileで実行するコマンドごとにレイヤーが追加される」、「レイヤーにはデータが残るので、秘密情報をコンテナの中で処理しない(ファイルを消してもレイヤーにその情報が残る)」という点です。

実際にレイヤーからシークレット情報を抜き出す方法がNECさんのサイトのブログに書かれていましたので、興味があればご覧ください。diveというものを使っているようです。

jpn.nec.com

Dockerとイメージ作成

Dockerでカスタマイズしたイメージをビルドするには、Dockerfileを使った方法が便利です。 Dockerfileを作成し、イメージ作成毎ディレクトリーを作成して必要なファイルを配置します。

このDockerfileには、FROMとADD、EXPOSEという命令が書かれています。 他の命令についてはDockerfile referenceに一覧があります。

FROMはこのイメージのベースとなるイメージを指定しています。アプリケーションはPHPベースなので、オフィシャルのPHPイメージを利用することにしました。 どのようなイメージがあるかはイメージの概要に書かれています。PHPイメージの場合、PHP CLIが使えるイメージ、Apache httpdがインストール済みのイメージ、PHP-FPM(FastCGI)が設定されているイメージ、Alpine LinuxベースのOSにPHPがインストールされたイメージなどが存在します。いくつかのOSバージョンの選択肢もあります。私がよく使うのは、DebianベースのApache httpdがセットアップ済みのイメージです。

FROM docker.io/php:7.4.30-apache-bullseye
ADD index.php /var/www/html/

EXPOSE 80

ADDは書かれている処理からもわかるように、ファイルを似にの場所にコピーするための命令です。 EXPOSEはポートの紐付けをします。

Dockerfile自身及びDockerfileで追加するファイルは同じディレクトリーにおいておくほうが良いです。 うっかり色々なファイルが存在するディレクトリーでDockerfileを使ったdocker buildを実行すると大変なことになります。

index.php

<html>
  <body>
    <h1>index</h1>
    <?php 
    echo("Hello World!");
    ?>
   </body>
 </html>

前の項で説明したDockerfileとindex.phpを同じ空のディレクトリーにおいてください。 そのディレクトリー上で次のコマンドを実行すると、独自のコンテナイメージを作成できます。

% ls
Dockerfile  index.php

$ docker image build -t myphp .

ビルド中の出力例

% docker image build -t myphp .
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM docker.io/php:7.4.30-apache-bullseye
7.4.30-apache-bullseye: Pulling from library/php
60197a4c18d4: Already exists 
c70b8381cf88: Pull complete 
15f3ec5d54b5: Pull complete 
dad5f9a74330: Pull complete 
56f09025ca19: Pull complete 
7d0ccca34338: Pull complete 
2119cf4cc65e: Pull complete 
aadc3826eeed: Pull complete 
56e72d660287: Pull complete 
bb2f331a1023: Pull complete 
270328af282b: Pull complete 
9c91d9d50cf0: Pull complete 
b71ad334b920: Pull complete 
Digest: sha256:8fccf5f8f6b458645031e7e91528fe94308eada08c70b9fe9795926a4f7c60dd
Status: Downloaded newer image for php:7.4.30-apache-bullseye
 ---> 6e17013fe942
Step 2/3 : ADD index.php /var/www/html/
 ---> 64cd59634cf3
Step 3/3 : EXPOSE 80
 ---> Running in adc11aa685f3
Removing intermediate container adc11aa685f3
 ---> a72dab5842bb
Successfully built a72dab5842bb
Successfully tagged myphp:latest

イメージの確認をしてみましょう。結果が出てくればイメージは問題なくできています。

% docker image ls | grep myphp
myphp   latest     a72dab5842bb   47 seconds ago   421MB

作成したイメージでコンテナを作成してみましょう。

% docker container run -d -p 8080:80 -it myphp

次のように実行すると、CLIでアプリケーションにアクセスできます。 同じマシン上でブラウザでURLにアクセスすると、HTMLが整形された状態で表示されます。

% curl http://localhost:8080
<html>
  <body>
    <h1>index</h1>
    Hello World!   </body>
 </html>

Dockerfileを使ったイメージ作成にはベストプラクティスが存在します。 Dockerの場合は次の通り公式の情報がドキュメントサイトに掲載されていますので、そちらを一読してください。

追加で注意する点としては次のようなものがあります。

  • 最新として提供されているイメージが古い(脆弱性が残っている)場合があるので、その場合はベースOSの流儀にしたがって更新する。

一般的にはコンテナレジストリーに公開されているコンテナイメージの一番新しいビルドのイメージを使えば良いとされていますが、イメージの更新間隔はイメージのよってまちまちなので、Dockerfileの中でベースイメージのアップデートの処理を入れたほうが良いと思います。

例えば次のような感じです。RUN行に「apt-get -y upgrade」と書かれています。

FROM docker.io/ubuntu:22.04
# Runs as root:
RUN apt-get update && apt-get -y upgrade && apt-get install -y python3 && rm -rf /var/lib/apt/lists/*

# Switch to non-root user:
RUN useradd --create-home appuser
WORKDIR /home/appuser
USER appuser
ADD test.py /home/appuser/

# Runs as non-root user:
ENTRYPOINT ["python3", "test.py"]
  • ベースイメージに含まれるアプリケーションのモジュールをインストールする場合は、まずイメージの仕様を確認する。

例えば今回使ったPHPイメージには、Apacheモジュールを有効にするためのコマンドが用意されています。モジュールがないというメッセージだけで判断して「apt-getコマンド」などでモジュールパッケージをインストールしようとすると、サーバーとモジュールの依存関係の不整合になるので問題です。実際はモジュールパッケージがインストールされることはないのですが万が一の場合もあるので、うまくアプリケーションが動かない時は「説明書」をよく読みましょう。

Dockerをアプリケーション開発に使う

Visual Studio CodeにDocker拡張とRemote Development拡張をインストールしてRancher Desktopと組み合わせて使うと、 コンテナベースでアプリケーション開発ができるようになります。

詳細は次をご覧ください。

Rancher DesktopでKubernetesを動かす

Rancher DesktopでKubernetesが有効化されていれば、Rancher Desktopを起動するだけでKubernetesクラスタが利用可能になります。Docker Desktopにも簡単にKubernetesを動かすためのオプションはありますが、Rancher Desktopの場合はクラスタのバージョンを選択できます。またクラスター自体はk3sで動かすため、軽量なKubernetesクラスタとして動かせます。

  • Kubernetesのバージョンは自由に選べます。Dockerだけを使いたいときはKubernetesをオフにすると、CPUやメモリー等の節約になります。

  • ランタイムはcontainerdとDockerから選べます。

前述の開発用途でも使いたい場合は、Dockerを選択するようにします。

以上、今回はRancher Desktopのご紹介でした。