docker-compose で bundle install したり、ビルドしようとするとエラーが発生。 色々試していたところ、grpc をインストールするステップで必ず失敗していること確認。 docker-compose run web gem install grpc #=> Installing grpc 1.43.1 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. ... 省略 ... ERROR: 137 alpine Linuxが悪さをしている？という記事を見てビルドイメージを変更するが改善せず。 結論、docker-compose.yml で platform を明示することで動作するようになった。 以下、実行時のファイル内容を残しておきます。 # ディレクトリ構成 root/ ├ Gemfile ├ Gemfile.lock ├ Dockerfile └ docker-compose.yml # Dockerfile FROM ruby:3.0.1 build-essential \ libpq-dev \ nodejs \ default-mysql-client \ yarn WORKDIR 'app' COPY ./Gemfile* ./ RUN bundle install # docker-compose.yml version: '3.8' services: ruby: platform: linux/x86_64 #=> 追加 build: context: ./ dockerfile: Dockerfile volumes: - ./:/app - ruby-bundle:/usr/local/bundle stdin_open: true tty: true volumes: ruby-bundle: # Gemfile gem 'google-cloud-pubsub' gem 'grpc' gem 'google-protobuf' gem 'pristine'

タイトルのままです。 概要 もうタイトルで伝えてたいことは書ききったのですが、せっかくなので経緯を述べておきます。 AWS FargateでNginxとLaravelコンテナをデプロイしていました。 以前、パフォーマンスチューニングでNginxのconfigファイルの設定について、こちらの記事を参考にゴニョゴニョしていたのですが、それからしばらくたった後、あることに気づきました。以下はfargateにNginxコンテナをデプロイした直後のコンテナログです。 [alert] 29#29: setrlimit(RLIMIT_NOFILE, 180000) failed (1: Operation not permitted) なんとworker_rlimit_nofileの設定が失敗している！？ 原因追求したところ、どうやら上で設定している180000という数字がよくなかったようです。 原因 Fargateにコンテナをデプロイするには、「タスク定義」を設定する必要がありますが、このタスク定義で設定していたulimits値を超えていたことが原因でした。 task-definition.json(抜粋) "containerDefinitions": [ { "ulimits": [ { "name": "nofile", "softLimit": 65536, "hardLimit": 65536 } ], } ここでulimits値をソフト/ハード共に65536に設定しているので、worker_rlimit_nofileの値は"65536以下"にする必要があるようです。 nginx.confファイルを再設定後、無事にこのエラーは解消されました。 nginx.conf #worker_rlimit_nofile 180000; コメントアウト worker_rlimit_nofile 65536; events { #worker_rlimit_nofileの値を3で割った数 worker_connections 21800; } このworker_rlimit_nofileの値は、woeker_processesの数によって変わるので注意が必要です。 今回のコンテナはCPUが1個でprocess数も1つの想定だったので、ulimit値とイコールにしています。 ちなみになぜ当初worker_rlimit_nofile値を180000にしていたのかについてですが、fargateコンテナでcat /proc/sys/fs/file-maxコマンドを叩き、「OSのファイルディスクリプタの最大数」として表示された数375274の2で割った数を設定していたからでした。 Fargateではその考え方は通用せず、タスク定義のulimits値=「1プロセスのファイルディスクリプタの最大数」が優先される、ということですね。 ちなみにFargateコンテナ上でulimit -Sn(ソフトulimitを確認するコマンド)を叩いたところ、確かに65536となっていました。 簡単にファイルディスクリプタ関連の用語についてまとめますと 用語 意味 ファイルディスクリプタ　 OS上でファイルに振られる番号で、ファイルを識別するための目印 OSで扱えるファイルディスクリプタ上限 OSで開くことのできる最大ファイル数。cat /proc/sys/fs/file-maxで確認可能 ソフトulimit １プロセスあたり使用できるファイルディスクリプタの上限。一般ユーザーも設定可能（ただしハードulimitの数値以下まで）。ulimit -Snで確認可能 ハードulimit １プロセスあたり使用できるファイルディスクリプタの上限。rootユーザーのみ設定可能。ulimit -Hnで確認可能。 worker_rlimit_nofile Nginxで設定するパラメータ。1workerあたりで開ける最大ファイル数を設定する。 ちなみに余談ですがFargateではタスク定義でulimit値を設定してやらないとデフォルトで以下の値に設定されますので気をつけましょうね。 ソフトulimt 1024 ハードulimt 4096 感想 やはりFargateは奥深い・・・。

タイトルのままです。 概要 もうタイトルで伝えたいことは書ききったのですが、せっかくなので経緯を述べておきます。 AWS FargateでNginxとLaravelコンテナをデプロイしていました。 以前、パフォーマンスチューニングでNginxのconfigファイルの設定について、こちらの記事を参考にゴニョゴニョしていたのですが、それからしばらくたった後、あることに気づきました。以下はfargateにNginxコンテナをデプロイした直後のコンテナログです。 [alert] 29#29: setrlimit(RLIMIT_NOFILE, 180000) failed (1: Operation not permitted) なんとworker_rlimit_nofileの設定が失敗している！？ 原因追求したところ、どうやら上で設定している180000という数字がよくなかったようです。 原因 Fargateにコンテナをデプロイするには、「タスク定義」を設定する必要がありますが、このタスク定義で設定していたulimits値を超えていたことが原因でした。 task-definition.json(抜粋) "containerDefinitions": [ { "ulimits": [ { "name": "nofile", "softLimit": 65536, "hardLimit": 65536 } ], } ここでulimits値をソフト/ハード共に65536に設定しているので、worker_rlimit_nofileの値は"65536以下"にする必要があるようです。 nginx.confファイルを再設定後、無事にこのエラーは解消されました。 nginx.conf #worker_rlimit_nofile 180000; コメントアウト worker_rlimit_nofile 65536; events { #worker_rlimit_nofileの値を3で割った数 worker_connections 21800; } このworker_rlimit_nofileの値は、woeker_processesの数によって変わるので注意が必要です。 今回のコンテナはCPUが1個でprocess数も1つの想定だったので、ulimit値とイコールにしています。 ちなみになぜ当初worker_rlimit_nofile値を180000にしていたのかについてですが、fargateコンテナでcat /proc/sys/fs/file-maxコマンドを叩き、「OSのファイルディスクリプタの最大数」として表示された数375274の2で割った数を設定していたからでした。 Fargateではその考え方は通用せず、タスク定義のulimits値=「1プロセスのファイルディスクリプタの最大数」が優先される、ということですね。 ちなみにFargateコンテナ上でulimit -Sn(ソフトulimitを確認するコマンド)を叩いたところ、確かに65536となっていました。 簡単にファイルディスクリプタ関連の用語についてまとめますと 用語 意味 ファイルディスクリプタ　 OS上でファイルに振られる番号で、ファイルを識別するための目印 OSで扱えるファイルディスクリプタ上限 OSで開くことのできる最大ファイル数。cat /proc/sys/fs/file-maxで確認可能 ソフトulimit １プロセスあたり使用できるファイルディスクリプタの上限。一般ユーザーも設定可能（ただしハードulimitの数値以下まで）。ulimit -Snで確認可能 ハードulimit １プロセスあたり使用できるファイルディスクリプタの上限。rootユーザーのみ設定可能。ulimit -Hnで確認可能。 worker_rlimit_nofile Nginxで設定するパラメータ。1workerあたりで開ける最大ファイル数を設定する。 ちなみに余談ですがFargateではタスク定義でulimit値を設定してやらないとデフォルトで以下の値に設定されますので気をつけましょうね。 ソフトulimt 1024 ハードulimt 4096 感想 やはりFargateは奥深い・・・。

事象・事前切り分け Docker上に構築したPostgreSQLにパスワードが合っていないとエラーが出る psqlコマンドでDocker環境内からのアクセスには問題ない事を確認した 解決 Docker上に構築したPostgreSQLデータベースへの接続(A5SQL)が上手く行かず ↓ 当初パスワードが違うとのエラーでDocker側のパスワード設定を確認するもパスワードは合っている ↓ 原因を調べたところ接続側(Windows)にもPostgreSQLが動いておりポートが同じ(5432)で干渉していた ↓ Windows側のPostgreSQL Serviceを止めて対応で解決できそうだが、職場PCの為不可 ↓ docker-compose.ymlを以下の様に変更して、Dockerイメージを再作成 version: '3.1' services: pg: image: postgres:latest ports: - "5433:5432" ←"接続からの接続ポート:DockerのPostgreSQLポート"なので左のポートを変更 enviroment: - xxxx ↓ docker-compose up ↓ 無事起動

Windows上のDockerを使ってbitnamiのmoodleを構築してみる bitnamiのmoodleを使って構築してみます bitnami-docker-moodleをcloneする コマンド git clone https://github.com/bitnami/bitnami-docker-moodle.git console PS C:\Users\user\Documents\Work\moodle> git clone https://github.com/bitnami/bitnami-docker-moodle.git Cloning into 'bitnami-docker-moodle'... remote: Enumerating objects: 12154, done. remote: Counting objects: 100% (2307/2307), done. remote: Compressing objects: 100% (884/884), done. remote: Total 12154 (delta 1056), reused 2270 (delta 1025), pack-reused 9847 Receiving objects: 100% (12154/12154), 1.39 MiB | 3.22 MiB/s, done. Resolving deltas: 100% (5310/5310), done. cloneできた！ docker-compose.ymlを編集する コマンド cd bitnami-docker-moodle/3/debian-10 このままでは、起動したときにmariaDBに外部から接続できないので、少し編集します portsを追加 docker-compose.yml version: '2' services: mariadb: image: docker.io/bitnami/mariadb:10.3 environment: # ALLOW_EMPTY_PASSWORD is recommended only for development. - ALLOW_EMPTY_PASSWORD=yes - MARIADB_USER=bn_moodle - MARIADB_DATABASE=bitnami_moodle - MARIADB_CHARACTER_SET=utf8mb4 - MARIADB_COLLATE=utf8mb4_unicode_ci ports: - '3306:3306' volumes: - 'mariadb_data:/bitnami/mariadb' (省略) docker-composeで起動する docker-composeで起動します コマンド docker-compose up -d comsole PS C:\Users\user\Documents\Work\moodle> cd bitnami-docker-moodle/3/debian-10 PS C:\Users\user\Documents\Work\moodle\bitnami-docker-moodle\3\debian-10> docker-compose up -d Pulling mariadb (docker.io/bitnami/mariadb:10.3)... 10.3: Pulling from bitnami/mariadb be4dd8fa80cd: Pull complete ...(略) 905ad56c9081: Pull complete Digest: sha256:afc2c90bf563ac11db5d3bd604eb72fa055094b1f7df37230c4ed8f730d48607 Status: Downloaded newer image for bitnami/mariadb:10.3 Pulling moodle (docker.io/bitnami/moodle:3)... 3: Pulling from bitnami/moodle be4dd8fa80cd: Already exists 0a3e0de7c251: Pull complete ...(略) 38265e4caeb7: Pull complete Digest: sha256:6928a6477558ed60f2f98074c43f7cfe156a86f16da55beeba53dd61bfda6cc3 Status: Downloaded newer image for bitnami/moodle:3 Creating debian-10_mariadb_1 ... done Creating debian-10_moodle_1 ... done 起動した！ console PS C:\Users\akasaka.hidetoshi\Documents\Work\moodle\bitnami-docker-moodle\3\debian-10> docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 414a749427cb bitnami/moodle:3 "/opt/bitnami/script…" 16 minutes ago Up 16 minutes 0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp debian-10_moodle_1 7dd8dc2b1514 bitnami/mariadb:10.3 "/opt/bitnami/script…" 16 minutes ago Up 16 minutes 0.0.0.0:3306->3306/tcp debian-10_mariadb_1 ブラウザでアクセスしてみる url https://localhost/ アクセスできた！ ログインしてみる ユーザID、パスワードはこの手順で構築すると下記の通りとなっています bitnamiデフォルトのログイン情報 user : user password : bitnami 画面右上のLog inをクリックしログイン情報を入力 ログインできた！ おまけ docker-compose.ymlを編集したおかげで、A5mk2から接続できます 項目 設定値 ホスト名 localhost127.0.0.1 ポート番号 3306 ユーザ名 bn_moodle パスワード <空> データベース bitnami_moodle 文字コード utf8mb4 接続できた！

VsCodeの拡張機能「Remote-Containers」を利用してコンテナ上で「plantuml」を実行するための設定 業務端末で拡張機能を入れる場合、利用申請が必要になるがコンテナ上であれば申請がいらないということなので、その設定ファイルをメモとして残しておく。 動かすことを目的としているため、設定項目が理想的かどうかは要確認。 devcontainer.json { "name": "myjava", "dockerComposeFile": "docker-compose.yml", "service": "workspace", "workspaceFolder": "/var/sample_sandbox", "settings": { "editor.tabSize": 4 }, "shutdownAction": "stopCompose", "extensions": [ "jebbs.plantuml", "vscjava.vscode-java-pack" ] } docker-compose.yml version: "3" services: workspace: build: workspace command: sleep infinity volumes: - ../:/var/sample_sandbox/ ports: - 8000:8000 FROM openjdk フォルダ構成 C:. ├─.devcontainer │ devcontainer.json │ docker-compose.yml └─workspace Dockerfile

この記事について ■ 対象：IT初心者しょぼん君：(´･ω･`) ・初心者向け、イメージを掴むキッカケになることが目的の記事 ・砕いた理解であり、一部正確ではない場合があります。 ■ しょぼん君のぼやき しょぼん君：(´･ω･`)『コンテナで起動ってどゆこと』 コンテナとは 初めて コンテナ と聞くと、箱のようなイメージを持つかもしれませんね。 実際に港など見られる箱のコンテナと絡めた解説もよく見かけますが、個人的にはあまり単語にこだわらなくても良いかなと思います。 コンテナは一言で言うと、アプリケーションを動かす方法・場所のことです。 普段、開発したアプリを動かしたい！と思ったら、サーバー上にアプリケーションをデプロイをして動かします。この時アプリケーションはどこで動いているの？というとサーバーです。そりゃそうですね。 ところが、技術は進歩し、人類はとあるソフトウェアを利用しアプリケーションをプロセスとして稼働させました。そしてそれを「コンテナ」と名づけたのであった！ 〜 終 〜 しょぼん君：(´･ω･`)『終わるな』 簡易的な図ですが、イメージとしては下図のように基盤となるLinuxサーバーのOS機能(カーネルなど)を使い、コンテナランタイムと呼ばれるものがサーバーからリソースなどレンタルして、アプリをプロセスとして稼働させる場を提供しています。 そして、このような技術や提供される空間のことをコンテナと呼んでいます。 しょぼん君：(´･ω･`)『コンテナって言われたら、サーバーに直じゃないんだなぁって思おう』 別空間という点では、仮想サーバーと似ていると感じるかもしれませんが、仮想サーバーではOSレベルで仮想環境を分離するため目的やメリットが異なります（LinuxやWindowsなど様々なOSを混在させることが可能など） コンテナではOSを含まないことで軽量でありつつも、基盤となるLinuxサーバーのOSバージョンや他のアプリケーションの変更による影響が最小限になる点がメリットの1つです。また、別のサーバー上で同じアプリケーションを起動する際にも、コンテナランタイムが導入されていればすぐに同環境で起動することが可能であり、再利用性にも優れています。 しょぼん君：(´･ω･`)『環境依存が少ないのはいいね』 設定方法など、コンテナ起動までの流れは実際にコンテナを起動して体感してみましょう。 Docker コンテナは、Dockerなどのコンテナランタイムを含むコンテナを管理するためのソフトウェアを導入して利用します。 (0)Dockerインストール（Docker for Mac） まずは、Dockerをインストールします。利用するには Docker ID が必要です。 まだ持っていない場合は、以下から「Docker ID」を取得します。 ID取得後、ソフトウェアをダウンロードしましょう。 https://store.docker.com/editions/community/docker-ce-desktop-mac ダウンロードした「Docer.dmg」を実行し、作成した「Docker ID」でログインします。 アプリケーションからDockerを起動し、ターミナルでDockerコマンドが使えるか確認してみましょう 確認コマンド. % docker version (1) Dockerfile を作成 コンテナは、バージョンの指定や、ディレクトリ構成などの構築設定をコードベースで管理（Infrastructure as Code）します。 Dockerでは、Dockerfileと呼ばれる、構築内容が書かれたファイル（構築内容が書かれたレシピ）をベースにして構築するため、まずは任意のディレクトリでDockerfileを作成しましょう。 今回は流れを把握するために単純なサンプルファイルを用意しました。 Dockerfileを作成 % mkdir Docker && cd $_ && vi Dockerfile # 内容サンプル FROM ubuntu:18.04 RUN echo "Hello world" > /tmp/test FROM　<レポジトリ：タグ> コンテナの基になるイメージを指定。 FROM命令では、コンテナの基となるイメージを指定しますが、ローカルにない場合はDockerレジストリ（docker hub など）からダウンロードされます。 RUN　<コマンド> コマンドを実行 (2)Build Dockerfileからimageをビルド % docker build -t shobon_image:1.0 . Sending build context to Docker daemon 9.216kB Step 1/1 : FROM ubuntu:18.04 18.04: Pulling from library/ubuntu 35c102085707: Pull complete 251f5509d51d: Pull complete 8e829fe70a46: Pull complete 6001e1789921: Pull complete Digest: sha256:d1d454df0f579c6be4d8161d227462d69e163a8ff9d20a847533989cf0c94d90 Status: Downloaded newer image for ubuntu:18.04 ---> a2a15febcdf3 Successfully built a2a15febcdf3 Successfully tagged shobon_image:1.0 imageの確認 % docker images REPOSITORY TAG IMAGE ID CREATED SIZE shobon_image 1.0 df4620745396 16 seconds ago 64.2MB ubuntu 18.04 a2a15febcdf3 7 days ago 64.2MB (3)RUN_起動 起動し、プロセスとして動いたことを確認 % docker run --name shobon_contener -itd shobon_image:1.0 /bin/bash % docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES edb3215685ee shobon_image:1.0 "/bin/bash" 3 seconds ago Up 2 seconds shobon Dockerfileに記載した内容で構築されたか確認してみます。 コンテナ内部での確認 # execコマンドでコンテナ名やコンテナIDを指定し、コンテナにログインします。 % docker exec -it shobon /bin/bash # コンテナ内部に入れたので、作成したtestファイルが存在するか確認 root@edb3215685ee:/# ls /tmp/ test # OSのバージョン確認 root@edb3215685ee:/# cat /etc/os-release NAME="Ubuntu" VERSION="18.04.6 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.6 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic コンテナ内部にログインし、Dockerfileで設定した内容で構築されていることが確認できました。 しょぼん君：(´･ω･`)『Dcokerfikeで記載した内容でDockerプロセスとしてコンテナが起動するということがわかった』 ーENDー Tips お掃除 Dockerでコンテナを起動していると、たくさんのimageやpｓが溜まってくるので不要なものは削除します。 Dockerプロセスを確認し、停止、削除 % docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES edb3215685ee shobon_image:1.0 "/bin/bash" 29 minutes ago Up 29 minutes shobon % docker stop edb3215685ee edb3215685ee % docker rm edb3215685ee edb3215685ee この時点では、image残っているため再度起動することが出来ます。 imageも消してしまいましょう。 imageの一覧を確認し、対象のイメージを指定して削除 % docker images REPOSITORY TAG IMAGE ID CREATED SIZE shobon_image 1.0 6f2828748274 34 minutes ago 63.1MB % docker rmi 6f2828748274 Untagged: shobon_image:1.0 Deleted: sha256:6f282874827492876f496dfc26c1eb0174eec8a2ecec543f2b15d078c06f3d74 Appendix ■ リンク - しょぼん君シリーズの他記事(´･ω･`)

この記事について ■ 対象：IT初心者しょぼん君：(´･ω･`) ・初心者向け、イメージを掴むキッカケになることが目的の記事 ・砕いた理解であり、一部正確ではない場合があります。 ■ しょぼん君のぼやき しょぼん君：(´･ω･`)『コンテナ化ってどゆこと』 コンテナとは 初めて コンテナ と聞くと、箱のようなイメージを持つかもしれませんね。 実際に港などにある箱のコンテナと絡めた解説も見かけたことがあるかもしれませんが、個人的にはあまり単語にこだわらなくても良いかなと思います。 コンテナは一言で言うと、アプリケーションを動かす方法だったり場所のことです。 これまでは、開発したアプリを動かしたい！と思ったらサーバー上にアプリケーションをデプロイをして動かしていました。この時アプリケーションはどこで動いているの？というとサーバーです。そりゃそうですね。 この方法はポピュラーですし悪いということはありませんが 技術は進歩し、人類はとあるソフトウェアを利用しアプリケーションの依存関係などを1つにまとめプロセスとして稼働させました。そしてそれを「コンテナ」と名づけたのであった！ 〜 終 〜 しょぼん君：(´･ω･`)『終わるな』 簡易的な図ですが、イメージとしては下図のように基盤となるLinuxサーバーのOS機能(カーネルなど)を使い、コンテナランタイムと呼ばれるものがサーバーからリソースなどレンタルして、アプリをプロセスとして稼働させる場を提供しています。 そして、このような技術や提供される空間のことをコンテナと呼んでいます。 しょぼん君：(´･ω･`)『コンテナって言われたら、サーバーに直じゃないんだなぁって思おう』 別空間という点では、仮想サーバーと似ていると感じるかもしれませんが、仮想サーバーではOSレベルで仮想環境を分離するため目的やメリットが異なります（LinuxやWindowsなど様々なOSを混在させることが可能など） コンテナではOSを含まないことで軽量でありつつも、基盤となるLinuxサーバーのOSバージョンや他のアプリケーションの変更による影響が最小限になる点がメリットの1つです。また、別のサーバー上で同じアプリケーションを起動する際にも、コンテナランタイムが導入されていればすぐに同環境で起動することが可能であり、再利用性にも優れています。 しょぼん君：(´･ω･`)『環境依存が少ないのはいいね』 設定方法など、コンテナ起動までの流れは実際にコンテナを起動して体感してみましょう。 Docker コンテナは、Dockerなどのコンテナランタイムを含むコンテナを管理するためのソフトウェアを導入して利用します。 (0)Dockerインストール（Docker for Mac） まずは、Dockerをインストールします。利用するには Docker ID が必要です。 まだ持っていない場合は、以下から「Docker ID」を取得します。 ID取得後、ソフトウェアをダウンロードしましょう。 https://store.docker.com/editions/community/docker-ce-desktop-mac ダウンロードした「Docer.dmg」を実行し、作成した「Docker ID」でログインします。 アプリケーションからDockerを起動し、ターミナルでDockerコマンドが使えるか確認してみましょう 確認コマンド. % docker version (1) Dockerfile を作成 コンテナは、バージョンの指定や、ディレクトリ構成などの構築設定をコードベースで管理（Infrastructure as Code）します。 Dockerでは、Dockerfileと呼ばれる、構築内容が書かれたファイル（構築内容が書かれたレシピ）をベースにして構築するため、まずは任意のディレクトリでDockerfileを作成しましょう。 今回は流れを把握するために単純なサンプルファイルを用意しました。 Dockerfileを作成 % mkdir Docker && cd $_ && vi Dockerfile # 内容サンプル FROM ubuntu:18.04 RUN echo "Hello world" > /tmp/test FROM　<レポジトリ：タグ> コンテナの基になるイメージを指定。 FROM命令では、コンテナの基となるイメージを指定しますが、ローカルにない場合はDockerレジストリ（docker hub など）からダウンロードされます。 RUN　<コマンド> コマンドを実行 (2)Build 作成したDckerfileでビルドを実行すると image　が生成されます。 これはアプリケーションや依存関係を1つにまとめたファイルで、コンテナを起動するための元になります。 しょぼん君：(´･ω･`)『じゃあ再利用したい時は image を共有したらいいんだね』 ビルドの際は、管理しやすいように名前やタグをつけるのがオススメです。 今回は、shobon_imageという名前で、タグとしてバージョン1.0をつけてみました。 Dockerfileからimageをビルド % docker build -t shobon_image:1.0 . Sending build context to Docker daemon 9.216kB Step 1/1 : FROM ubuntu:18.04 18.04: Pulling from library/ubuntu 35c102085707: Pull complete 251f5509d51d: Pull complete 8e829fe70a46: Pull complete 6001e1789921: Pull complete Digest: sha256:d1d454df0f579c6be4d8161d227462d69e163a8ff9d20a847533989cf0c94d90 Status: Downloaded newer image for ubuntu:18.04 ---> a2a15febcdf3 Successfully built a2a15febcdf3 Successfully tagged shobon_image:1.0 imageの確認 % docker images REPOSITORY TAG IMAGE ID CREATED SIZE shobon_image 1.0 df4620745396 16 seconds ago 64.2MB ubuntu 18.04 a2a15febcdf3 7 days ago 64.2MB (3)RUN_起動 作成したイメージを指定し、コンテナを起動します。 起動したら、Dockerのプロセスとして動いたか確認してみましょう。 起動し、プロセスとして動いたことを確認 % docker run --name shobon_contener -itd shobon_image:1.0 /bin/bash % docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES edb3215685ee shobon_image:1.0 "/bin/bash" 3 seconds ago Up 2 seconds shobon Dockerfileに記載した内容で構築されたかコンテナ内部にログインして確認します。 コンテナ内部での確認 # execコマンドでコンテナ名やコンテナIDを指定し、コンテナにログインします。 % docker exec -it shobon /bin/bash # コンテナ内部に入れたので、作成したtestファイルが存在するか確認 root@edb3215685ee:/# ls /tmp/ test # OSのバージョン確認 root@edb3215685ee:/# cat /etc/os-release NAME="Ubuntu" VERSION="18.04.6 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.6 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic Dockerfileで設定した内容で構築されていることが確認できました。 しょぼん君：(｀・ω・´)『Dcokerfikeで記載した内容でDockerプロセスとしてコンテナが起動するということがわかった』 ーENDー Tips お掃除 Dockerでコンテナを起動していると、たくさんのimageやpｓが溜まってくるので不要なものは削除します。 Dockerプロセスを確認し、停止、削除 % docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES edb3215685ee shobon_image:1.0 "/bin/bash" 29 minutes ago Up 29 minutes shobon % docker stop edb3215685ee edb3215685ee % docker rm edb3215685ee edb3215685ee この時点では、image残っているため再度起動することが出来ます。 imageも消してしまいましょう。 imageの一覧を確認し、対象のイメージを指定して削除 % docker images REPOSITORY TAG IMAGE ID CREATED SIZE shobon_image 1.0 6f2828748274 34 minutes ago 63.1MB % docker rmi 6f2828748274 Untagged: shobon_image:1.0 Deleted: sha256:6f282874827492876f496dfc26c1eb0174eec8a2ecec543f2b15d078c06f3d74 Appendix ■ リンク - しょぼん君シリーズの他記事(´･ω･`)