コンテ内でsystemctlが使えない..... 業務でコピペしてコマンド使ってたらsystemctlコマンドで下記のエラーが出ちゃいました。 $ systemctl start mariadb.service Failed to get D-Bus connection: Operation not permitted どうやらcnetosやubuntuのコンテナ内ではsystemctlが使えないらしいです。 systemctlとは そもそもこのコマンドって何なの？ってところですが、systemctlはLinux系で利用されるサービスコントロールをするコマンドらしいです。 コンテナ内で使う方法 まずコンテナを起動する時に--privilegedオプションをつけ、/sbin/initで実行します。 # 例) docker run -d --privileged --name centos_container centos /sbin/iniｔ 次に起動したコンテナにアタッチします。 docker exec -it centos_container /bin/bash これで使えるようになるかと思います。

1.Gemfileに、deviseを追加後下記を実施。 $ docker-compose run web bundle install #deviseをインストールする $ docker-compose build #構築する。 2.deviseのインストール $ docker-compose run web bin/rails g devise:install 3.モデル、ビューの作成 $ docker-compose run web bin/rails g devise user $ docker-compose run web rake db:migrate $ docker-compose run web bin/rails g devise:views

1.プロジェクト作成 mkdir アプリ名 2.プロジェクトディレクトリでファイル５つ作成 Dockerfile docker-compose.yml Gemfile Gemfile.lock entrypoint.sh FROM ruby:2.7.0 ## nodejsとyarnはwebpackをインストールする際に必要 # yarnパッケージ管理ツールをインストール RUN apt-get update && apt-get install -y curl apt-transport-https wget && \ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && \ echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list && \ apt-get update && apt-get install -y yarn RUN apt-get update -qq && apt-get install -y nodejs yarn RUN mkdir /myapp WORKDIR /myapp COPY Gemfile /myapp/Gemfile COPY Gemfile.lock /myapp/Gemfile.lock RUN bundle install COPY . /myapp RUN yarn install --check-files RUN bundle exec rails webpacker:compile # Add a script to be executed every time the container starts. COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3000 # Start the main process. CMD ["rails", "server", "-b", "0.0.0.0"] docker-compose.yml version: '3' services: db: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: password MYSQL_DATABASE: root ports: - "3306:3306" volumes: - ./tmp/db:/var/lib/mysql web: build: . command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" volumes: - .:/myapp ports: - "3000:3000" depends_on: - db source 'https://rubygems.org' gem 'rails', '6.0.3' Gemfile.lock(空ファイル) entrypoint.sh # !/bin/bash set -e # Remove a potentially pre-existing server.pid for Rails. rm -f /myapp/tmp/pids/server.pid # Then exec the container's main process (what's set as CMD in the Dockerfile). exec "$@" 3.プロジェクトの作成 $ docker-compose run web rails new . --force --no-deps --database=mysql 4.コンテナをビルド $ docker-compose build 5.データベースファイルの修正 config/database.yml default: &default adapter: mysql2 encoding: utf8mb4 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: root password: host: localhost development: <<: *default database: myapp_development host: db username: root password: password test: <<: *default database: myapp_test host: db username: root password: password 6.データベースの作成 $ docker-compose run web rails db:create 7.webpackerのインストール $ docker-compose run web rails webpacker:install 8.コンテナの起動 $ docker-compose up -d 9.起動確認 ブラウザから localhost:3000 にアクセスし、Rails の初期画面が表示されることを確認

1.docker psコマンドでMySQLのコンテナを確認 % docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8c0d9a39d523 test_app "rails test test/int…" About a minute ago Up About a minute 3000/tcp, 3035/tcp test_app_run_cee0483ae56b 4254fa5eab39 mysql:5 "docker-entrypoint.s…" 5 days ago Up 6 hours 0.0.0.0:3306->3306/tcp, 33060/tcp test_db_1 2.MySQLコンテナに接続 % docker exec -it MySQLのコンテナ名 bash 今回の場合は「docker exec -it test_db_1 bash」となります。 3.MySQLにアクセス root@000000000:/# mysql -u root -p Enter password: 4.MySQLにアクセスできたら、存在するデータベースを確認します。 mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | myapp_development | | myapp_test | | mysql | | performance_schema | | sys | +--------------------+ 5 rows in set (0.10 sec) 5.その中から使用したい（中身をみたい）データベースを選択 mysql> use myapp_development; 6.さらにテーブルを確認 mysql> show tables; +-----------------------------+ | Tables_in_myapp_development | +-----------------------------+ | active_storage_attachments | | active_storage_blobs | | ar_internal_metadata | | test | | schema_migrations | | users | +-----------------------------+ 6 rows in set (0.00 sec) 7.最後に、テーブルを選択することでそこに保存されているデータを見ることができます。 mysql> select * from users; +----+-------+----------------+--------------------------------------------------------------+----------------------------+----------------------------+--------------+---------------+ | id | name | email | password_digest | created_at | updated_at | reset_digest | reset_sent_at | +----+-------+----------------+--------------------------------------------------------------+----------------------------+----------------------------+--------------+---------------+ | 1 | テスト | 123@gmail.com | $2a$12$9o6zvuNS8bKYGRI/xIBEpelGZOp0wwFADu.TLm2y0lTK9qt8W/bwy | 2021-01-06 07:08:49.771299 | 2021-01-06 07:08:49.771299 | NULL | NULL | | 2 | あああ | abc@gmail.com | $2a$12$RsFA2XWjEzWuo8uC4hmE0.rCOm3cAL6RGqbRtm/ysFAiRzpho1P4G | 2021-01-07 07:19:47.506578 | 2021-01-07 07:19:47.506578 | NULL | NULL | +----+-------+----------------+--------------------------------------------------------------+----------------------------+----------------------------+--------------+---------------+ 2 rows in set (0.00 sec)

Wordpressの開発環境をDockerで作ろうとしたところ、「Error establishing a database connection」というエラーメッセージが表示されてしまいました。少し詰まったので備忘録として書いておきます。 原因1：dockerのvolumeが残ってしまっていた。 解決策：docker volume pruneで未使用のvolumeを削除する。 docker-compose.ymlに下記のように記載していました。 docker-compose.yml ... db: image: mysql:5.7 restart: always environment: MYSQL_DATABASE: db MYSQL_USER: user MYSQL_PASSWORD: pass volumes: - db:/var/lib/mysql volumes: wordpress: db: このymlファイルで一度コンテナを起動後、ユーザー名やパスワードを変更して作業をしていたので、dbコンテナに入ってからmysqlに接続しようとしても「パスワードが違います」というメッセージが表示されてしまい、接続ができませんでした。 ymlファイルを見直し、「これ、volumeが残っているから修正した情報が反映されてないのでは...？」と気づき、docker volume pruneで古いvolumeを削除。再度コンテナを起動したところ、修正後の情報でmysqlへ接続できました。 原因2：wp-config.phpのDB_HOSTはDBコンテナ名 解決策：wp-config.phpのDB_HOSTをDBコンテナ名に変更する。 wp-config.php 修正前 /** MySQL のホスト名 */ define('DB_HOST', 'localhost'); ↓ 修正後 /** MySQL のホスト名 */ define('DB_HOST', 'db'); // ymlに記載したDBコンテナ名 wordpressの設定ファイルは、ルートディレクトリにwp-config-sample.phpがあるので、これをwp-config.phpとしてコピーを行い、使用します。この中にDBの接続情報が記載されているのですが、このDB_HOSTの値をdockerで作成するDBのコンテナ名に設定したところ、無事にWordpressの画面が表示されました。 最後に URLにhttp://localhost:8080/wp-admin/で接続すると、上記のような画面が表示されました。ここに表示されている「Are you sure you have typed the correct hostname?」を見て、原因2を疑うことができました。 それでは！ 参考情報： ・未使用のコンテナ、volumeなどを一括削除 https://qiita.com/reflet/items/5caa88abcf1e8964783a ・Docker: 使っていないボリュームを削除してディスク使用量を節約する https://hoge-hogeo-777.hatenablog.com/entry/2019/03/01/183000

Wordpressの開発環境をDockerで作ろうとしたところ、「Error establishing a database connection」というエラーメッセージが表示されてしまいました。少し詰まったので備忘録として書いておきます。 原因1：dockerのvolumeが残ってしまっていた。 解決策：docker volume pruneで未使用のvolumeを削除する。 docker-compose.ymlに下記のように記載していました。 docker-compose.yml ... db: image: mysql:5.7 restart: always environment: MYSQL_DATABASE: db MYSQL_USER: user MYSQL_PASSWORD: pass volumes: - db:/var/lib/mysql volumes: wordpress: db: このymlファイルで一度コンテナを起動後、ユーザー名やパスワードを変更して作業をしていたので、dbコンテナに入ってからmysqlに接続しようとしても「パスワードが違います」というメッセージが表示されてしまい、接続ができませんでした。 ymlファイルを見直し、「これ、volumeが残っているから修正した情報が反映されてないのでは...？」と気づき、docker volume pruneで古いvolumeを削除。再度コンテナを起動したところ、修正後の情報でmysqlへ接続できました。 原因2：wp-config.phpのDB_HOSTはDBコンテナ名 解決策：wp-config.phpのDB_HOSTをDBコンテナ名に変更する。 wp-config.php 修正前 /** MySQL のホスト名 */ define('DB_HOST', 'localhost'); ↓ 修正後 /** MySQL のホスト名 */ define('DB_HOST', 'db'); // ymlに記載したDBコンテナ名 wordpressの設定ファイルは、ルートディレクトリにwp-config-sample.phpがあるので、これをwp-config.phpとしてコピーを行い、使用します。この中にDBの接続情報が記載されているのですが、このDB_HOSTの値をdockerで作成するDBのコンテナ名に設定したところ、無事にWordpressの画面が表示されました。 最後に URLにhttp://localhost:8080/wp-admin/で接続すると、上記のような画面が表示されました。ここに表示されている「Are you sure you have typed the correct hostname?」を見て、原因2を疑うことができました。 それでは！ 参考情報： ・未使用のコンテナ、volumeなどを一括削除 https://qiita.com/reflet/items/5caa88abcf1e8964783a ・Docker: 使っていないボリュームを削除してディスク使用量を節約する https://hoge-hogeo-777.hatenablog.com/entry/2019/03/01/183000

エラー内容 Mac の docker で node を使っていたら、以下のようなエラーが出ました。 (node:1753) UnhandledPromiseRejectionWarning: Error: connect ECONNREFUSED 127.0.0.1:3306 3306 ということでMySQLに接続できていないようなので、dockerの方を見てみる。 すると以下のエラーが出ていました。 [error] --initialize specified but the data directory has files in it. aborting. どうやらファイルが存在していて失敗しているよう。 だがvolumeやめぼしいファイルを消してみたり、ネットを検索して出てきた記事では解決できませんでした。 解決策 結果としては以下で解決しました。 Docker の Menu から Troubleshoot を選択 Clean / Purge data をする Reset to factory defaults をする どっちが効いたのかわからないけどこれで直りました。

dockerで非常に躓いたので、備忘録として残します。 Dockerfileで躓いたところ 使うdocker-imageをFROMで指定する 当たり前ですが、imageをFROMで指定しないと何を書いても動きません。 FROM FROM centos:7 ※centos7はサポートが結構間近なので気をつけましょう docker-compose.ymlで躓いたところ volumsでカレントディレクトリを指定して、docker側のrootディレクトリに送るとホットリロードになる 神機能なのでみなさん使いましょう。 また、特に設定をしてない場合はrootユーザーで入るので、ホームディレクトリがrootとなります。 ホームディレクトリに移動させたいファイルやディレクトリを指定しましょう。 docker-compose volumes: - .:/root docker-compose.ymlに使うimageを書けばDockerfileが要らない ケースバイケースだとは思いますが、Dockerfileで何かごにょごにょと処理をしない場合には、管理がしやすいのでdocker-compose.ymlに書きましょう docker-compose.yml version: "3" services: db: image: mysql:5.7 #imageにdocker-imageを指定する container_name: mysql dockerが起動した瞬間すぐ落ちる時 tty: trueを付けましょう。永続的に起動します。 docker-compose.yml version: "3" services: db: image: mysql:5.7 container_name: mysql tty: true #永続的に起動させたいコンテナに付ける 悪魔のコード dockerの全てを破壊します。 最終手段で使いましょう。 dockerのimageやらネットワークやらを削除する docker image prune #可動していないdocker-imageを削除します docker container stop $(docker ps -aq) #可動している全てのdockerを停止します docker image rm $(docker images ls) #docker-imageを全て削除します また、dockerのコマンドは新しく(3年前に)なったそうです。こちらで確認しておきましょう。

チートリスト Dockerコンテナ一覧表示 $ docker ps -a Dockerコンテナの削除 $ docker rm [コンテナID] $ docker rm -f [コンテナID] //消えない場合 Dockerイメージ一覧表示 $ docker images Dockerイメージの削除 $ docker rmi [イメージID] $ docker rm -f [コンテナID] //消えない場合 Docker Hubからイメージの取得 docker pull [OPTIONS] NAME[:TAG|@DIGEST] apacheイメージの取得 $ docker pull httpd Dockerイメージからコンテナの作成・起動・停止 docker run [OPTIONS] IMAGE [COMMAND] [ARG...] $ docker run -d -p 8080:80 httpd ポートがLISTENしているか確認 $ sudo lsof -i -P | grep "LISTEN" コンテナの停止 $ docker stop [コンテナID] コンテナの起動 $ docker start [コンテナID] Dockerコンテナにシェルで入る $ docker exec -i -t [コンテナID] /bin/bash ボリュームのマウントオプション(永続化) docker run -v "マウント元(ゲストOS):マウント先(コンテナ)" $ docker run -d -p 80:80 -v "/home/developer/docker/htdocs/:/usr/local/apache2/htdocs/" httpd リファレンス Apache Docker Hub - httpd Docker 公式 httpd イメージを利用して Docker を体験してみよう

この度Play frameworkの環境をDockerで構築してみたのでメモ。 使用するdocker image 今回使用したDocker imageはこちら hseeberger/scala-sbt mysql sbtのimageに関してはhseebergerさんが作成したものがあったので使わせてもらいます。 また、データベースにmysqlを使用するのでmysqlのimageも使います。他のデータベースを使う場合は使いたいデータベースのimageを用意してください。 作成したdocker-compose.yml 複数のコンテナを使う場合はdocker-composeを使うと便利です。 playframeworkのプロジェクトに以下のymlファイルを作成しました。 docker-compose.yml version: '3' services: sbt: build: . image: hseeberger/scala-sbt:8u222_1.3.5_2.13.1 container_name: sbt volumes: # このプロジェクト自体をコンテナ内の/rootディレクトリにマウント - .:/root ports: - 9000:9000 expose: - "9000" tty: true db: image: mysql:5.7 container_name: mysql environment: MYSQL_DATABASE: playdb MYSQL_USER: hoge MYSQL_PASSWORD: hogepassword MYSQL_ROOT_PASSWORD: hogepassword volumes: - ./db/data:/var/lib/mysql # データを永続化するためローカルにデータをマウント - ./db/sql:/docker-entrypoint-initdb.d # 初期データの投入関係 - ./db/my.cnf:/etc/mysql/conf.d/my.cnf # 文字コード設定用 ports: - "3306:3306" expose: - "3306" play framework側の設定 play frameworkにmysqlを導入するための設定をします。 build.sbtとapplication.confに以下のコードを追加します。 build.sbt libraryDependencies += "mysql" % "mysql-connector-java" % "5.1.41" application.conf db.default.driver=com.mysql.jdbc.Driver db.default.url="jdbc:mysql://db:3306/playdb" #コンテナ名:ポート番号/データベース名 db.default.username=hoge db.default.password=hogepassword 詳しいことはplayframeworkの公式ドキュメントを参照してください。 dockerでmysqlを導入するときの注意点 dockerのmysqlはデフォルトのままだと latin1という日本語を扱えない文字コードが設定されているのでutf8やutf8mb4に変更しないといけません。 方法はいくつかありますが、私はmy.cnfファイルを使いました。 プロジェクトにdbディレクトリをつくり、そこに以下のmy.cnfファイルを作成して文字コードを指定します。 my.cnf [mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_general_ci explicit-defaults-for-timestamp=1 general-log=1 general-log-file=/var/log/mysql/mysqld.log [client] default-character-set=utf8mb4 先程のdocker-compose.ymlにもありましたが、これをdockerコンテナ内のetc/mysql/conf.d/my.cnfにマウントします。 docker-compose.yml volumes: - ./db/my.cnf:/etc/mysql/conf.d/my.cnf # 文字コード設定用 こちらが参考にした記事。 これでmysqlで日本語を扱えるようになります。 ただし変更前に一度作成したテーブルの文字コードはそのままになっているので自分で変更する必要があります。 mysqlの永続化 また、Dockerでmysqlを導入した場合、気をつけないといけないのがデータの永続化についてです。 当然ですがmysqlに保存したデータはmysqlのコンテナが持っているので、もしmysqlのコンテナを削除したら保存したデータも一緒に消えてしまいます。 それでは困るのでデータはコンテナだけでなくローカル側にも持たせてデータを永続化しましょう。 今回docker-compose.ymlにて以下のコードを記述してコンテナ内のデータをローカルにも持たせています。 docker-compose.yml volumes: - ./db/data:/var/lib/mysql # データを永続化するためローカルにデータをマウント 参考にした記事

問題発生 Dockerを使ってアプリケーション(Laravelなど)からMySQLに接続する(php artisan migrateなどで)時に、 接続できません！！ とターミナルで怒られてしまったのですが、 Sequel Proを見ても動いているし、 MySQLのコンテナに入っても動いているので原因がわからず、 envファイルが違うのかなんなと原因究明していて迷走していたので記事にしました。。。 結論 MySQLの認証方式が「mysql_native_password」ではなく、なぜか「caching_sha2_password」を使う必要があったため。 ただ、Sequel Proでは「caching_sha2_password」使えないから「mysql_native_password」を使えよと怒られたので、 使ってみたんですが、この場合はアプリケーションとMySQLは接続できたのでSequel Proを動かしてみたら以下のように怒られてしまいました。 →Sequel Proで使うために「mysql_native_password」を使用したからこんなことになってしまったのです。 多分MySQL8.0以降を使うならMySQL Workbenchとか別のもの使った方がいいのか？ Sequel Pro Nightly build より MySQL said: Authentication plugin 'caching_sha2_password' cannot be loaded: dlopen(/usr/local/mysql/lib/plugin/caching_sha2_password.so, 2): image not found まとめ MySQL8.0.4以降 のログイン認証方式は caching_sha2_password がデフォルト PHP 7.1.16, 7.2.4 以降のバージョンから caching_sha2_password に対応しているので「caching_sha2_password」をそのまま利用する しかし、Sequel Pro Nightly buildでは「caching_sha2_password」を使用できない 以上、Sequel ProとMySQL8.0以降を使用する機会があったらご注意ください。(Sequel Pro不具合多いし、MySQL Workbench使った方がいいのかな...) ほんと環境設定とかで止まるのが辛いです。 参考文献 https://www.suzu6.net/posts/256-mysql8-pdomysql-caching_sha2_password/ https://qiita.com/ucan-lab/items/3ae911b7e13287a5b917 https://qiita.com/ucan-lab/items/b68db1db931c954da921

Windows 10にAerospikeの Community Edition (Docker) をインストールしたときのメモ。 Install on Windows https://download.aerospike.com/docs/operations/install/docker/win/index.html 公式サイトのこのページには、Enterprise Editionの話しか書いてなく、Community Editionはどうやって入れるのか分からなかった。 Using Vagrant On Windows https://download.aerospike.com/docs/operations/install/vagrant/win/using-vagrant.html ちなみにCommunity Edition は Vagrantを使う以前からの方法もあったけれど、deprecatedになりDocker版を使えと書いてあった。。。 （Install on Windowsページの左側のメニューのInstall on Windowsの左の＋をクリックするとこのページが出てくる。ちなみにこのページのリンクをクリックしても、上のInstall on Windowsページにリダイレクトされて表示されない！ので見つけるのに苦労した。この方法ではやってほしくないのか隠されてるっぽい（笑）） 探していたら、DockerのCommunity Edition あるらしい事がわかった。 https://qiita.com/suganury/items/b3cdcf4fd2cb2eba66ac 今回はこれを使う。 1 Docker インストール Dockerが必要なので、 ここから、まずDocker Desktopをインストールした。 https://hub.docker.com/editions/community/docker-ce-desktop-windows/ 2 インストール コマンドプロンプトで、 docker pull aerospike:ce-[version] https://hub.docker.com/_/aerospike の Supported tags and respective Dockerfile links を見て、 例えばce-5.6.0.4なら、 docker pull aerospike:ce-5.6.0.4 とする。 3 起動 docker run -d -v DIR:/opt/aerospike/etc/ --name aerospike -p 3000:3000 -p 3001:3001 -p 3002:3002 aerospike:ce-[version] docker runコマンドでコンテナを作成した後は、Docker DesktopのUIでも起動や停止（startやstop）できる。 4 ログイン docker exec -it aerospike /bin/bash 5 AQL で操作 SQLのようなクエリ言語AQL(Aerospike Query Language)でAerospike を操作する。 aql でAQLを起動。 quit でAQLを終了。 6 Docker ログアウト "control"を押した状態で"P、Q"を順番に押す。 参考にしたページ

はじめに 最近仕事用の PC が異音を出すようになったため、新しい PC に交換してもらった。せっかくのまっさらな PC なので、新たなことを試していこうと思う。 これまでの開発では、WSL2 上に仮想環境を作成することで開発を行ってきたが、複数人で開発する際には各々の実行環境が異なっていることが多く、その度に確認することが手間だった。また仮想環境のアクティベートを忘れてローカル環境を変更してしまうことも何度かしてしまっていた。そこで今回の PC 故障を機に開発環境統一化やローカル環境のクリーン化を目指し Docker での開発環境構築に取り組んでみる。 想定する Docker 開発環境ルール 以下のようなルールを想定。言語が異なってもすべて VSCode で扱える「統一性」と VSCode 拡張機能もコンテナごとに設定するなど「ローカル環境のクリーンさ」を重視した。 ローカルの Windows と開発関連は完全に分離（ファイルも WSL2 上に配置） 開発環境はすべて Docker コンテナ上に作成 コンテナイメージは Dockerfile により作成（追加パッケージがあれば必ず追記） ファイルへのアクセスは基本的に VSCode を使用 VSCode Extensions やポートをコンテナごとに設定 WSL2 のインストール Docker のバックグラウンドで使用するためインストールする。Hyper-V よりもパフォーマンスが良く、また WSL2 環境自体も容易に再構築できるため Windows 環境を汚さなくてもさまざまなことを試せるのが嬉しい。 Windows 10 用 Windows Subsystem for Linux のインストール ガイドを参考にした。参考サイトにある WSL2 の実行要件を見て問題がないことを確認。 まず「Windows の機能の有効化または無効化」で以下項目のチェックボックスをオンにして、PC を再起動する。 Linux 用 Windows サブシステム 仮想マシン プラットフォーム 次に x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージをダウンロードして実行する。次に PowerShell を管理者権限で実行し、以下コマンドで WSL2 を既定のバージョンとして設定する。 PS > wsl --set-default-version 2 最後に Microsoft Store から Linux ディストリビューションを選択し、インストールする。ここでは、Ubuntu-20.04 を選択した。インストール後に起動して、ユーザーアカウントとパスワードを設定したら WSL2 のセットアップは完了。ついでに.bashrc には以下設定を追記しておく。コマンドの履歴を補完してくれるのが便利。 .bashrc ... # User specific aliases alias ls='ls -G' alias la='ls -a' alias rm='rm -i' alias mv='mv -i' alias cp='cp -i' alias ..='cd ..' # 履歴補完前方一致 bind '"\C-n": history-search-forward' bind '"\C-p": history-search-backward' # 上矢印キー bind '"\e[A": history-search-backward' # 下矢印キー bind '"\e[B": history-search-forward' あとはディレクトリ構成を見るのに便利な tree を sudo apt install tree でインストールしておく。 Docker Desktop のインストール 肝心要の Docker を入れていく。インストール自体は非常に簡単。 Docker Desktop for Mac and Windows からセットアップファイルをダウンロードして実行。途中の設定では「Install required Windows components for WSL 2」 にチェックを入れたままで進める。 VSCode のインストール VSCode をインストールする。インストール先は Windows となるが、（後述の拡張機能を用いて）基本的には WSL2 上から開くことを想定している。 Visual Studio Code からセットアップファイルをダウンロードして実行。追加タスクの設定ではデフォルトのまま 「PATH への追加」のみチェック。この設定で WSL 上で code . などで VSCode を実行できるようになる。Windows 上でフォルダやファイルを VSCode で開くことはないのでその他はチェックしない。 VSCode 拡張機能の追加 次に、拡張機能を入れていく。以下は Docker 開発環境に必須なもの。 Docker Remote Containers Remote WSL Docker Dockerfile や docker-compose.yml の編集時のサポート、Docker イメージやコンテナ、ネットワークといったものの状況を VSCode 上で把握できるようになる。その他にも機能があるが、コンテナの状況を簡単に見ることができ、GUI で削除などもできるのが便利。 Remote Containers 以下2つのファイルで設定を行う。 devcontainer.json：VSCode 上のコンテナ設定ファイル Dockerfile ：Docker イメージ作成ファイル VSCode 画面左下の緑 [><] をクリックすると、Add Development Container Configuration Files... を選択すると、.devcontainer ディレクトリが作成され、その配下に上記2つのファイルが作成される。またその際、使用する言語などに合わせてサンプルも使用できる。詳細は Get started with development Containers in Visual Studio Code を参照。 基本的にはサンプルを参考に細かい部分を自分用にカスタマイズ（コンテナごとの拡張機能の設定など）すればよい。devcontainer.json に関しては devcontainer.json reference に詳細が記載されている。 Remote WSL WSL2 上で code . などの実行により VSCode による編集が可能。開発自体は Docker 環境で行うが、開発関連のファイルを WSL2 上に置く想定なので、「一度 WSL2 上のプロジェクトディレクトリから VSCode に接続」→「 VSCode 画面左下の緑 [><] からコンテナ環境に接続し直す」ことを想定している。また .bashrc など WSL2 上自体の設定ファイルの編集にも使用できる。（vim を扱えないので VSCode with Emacs Key Binding で編集したい。。。） その他拡張機能 その他の便利な拡張機能はコンテナごとに設定したいので、必ず使用するもの以外はローカル VSCode にはインストールしない。私がローカルに入れたのは以下3つくらい。 Awesome Emacs Keymap（Emacs キーバインディングにできるありがたい機能） Bracket Pair Colorizer 2 vscode-icons おわりに 雑ではあるが、ひとまず自身の開発自体はできそうなのでここまでとする。今後使用していく中で勘違いやよりよい使い方などが出てくれば更新していきたい。

はじめに クラウドネイティブを勉強する際には避けては通れないのはKubernetes。そしてKubernetesを学ぶ上で避けては通れないのがDockerです。 しかし、Kubernetesを勉強する上で全てのdockerの知識が必要かと問われるとそうではありません。 この記事ではKubernetesを扱う上で必要最低限知っておきたい知識をまとめました。 この記事が次のステップKubernetesの世界への第一歩となれば幸いです。 また、この記事は日本のKubernetesの第一人者であるサイバーエージェントの青山さんが執筆しているKubernetes完全ガイドという非常に有名な本を参考にして書きました。 Kubernetes勉強本の中では1番メジャーです。 本格的に勉強していく方は早い段階で手に取っておくことをお勧めします。 Dockerとは Dockerとはコンテナを実行するための実行環境（コンテナランタイム）およびツールキットのこと。 今回の最終ゴールはKubeflowへの理解なので、Kubernetesを利用する際に必要なDockerの機能のみに焦点を絞ることにする。 Kubernetesを利用する際に知っていた方がいい知識は以下の通りです。 Dockerコンテナの設計 Dockerfileの書き方 Dockerイメージのビルド Dockerレジストリへのイメージのプッシュ Dockerコンテナとは DockerコンテナはDockerイメージカラ実行されるプロセスです。 Dockerイメージさえあれば様々な環境で起動可能なことからポータビリティ、再利用性が高いという特徴があります。また、dockerコンテナは仮想マシンに比べて軽量で高速です。これは仮想マシンがハイパーバイザーを利用してゲストOSを起動させるのに対し、Dockerはホストマシンのカーネルを利用するような作りになっているため、OSの起動時間を待つ必要がなくなるからです。 Dockerコンテナの設計 Dockerコンテナを作成する際に気をつけなければならない点が4つあります。 １コンテナにつき１プロセス Immutable Infrastructureなイメージにする 軽量なDockerイメージにする 実行ユーザをRoot以外にする この中で最も大切なのは「１コンテナにつき１プロセス」のみを起動するように作成することです。なぜなら、Dockerコンテナが1つのアプリケーションを実行するという思想のもと作られているので、この思想に反して複数のプロセスをイメージに組み込んでしまうと周辺のエコシステムとの相性が悪くなったり管理性が低くなったりしてしまいます。 次に大切なこととして、Immutable Infrastructureを実現するイメージにすることです。 これは、「環境を変更する際は古い環境は捨て新たに作る」、「1度作られた環境は変更されないことを徹底する」ということを意味します。前者はKubernatesでは自動で再生成されるので意識する必要はないですが、後者は開発者が意識してイメージの設計をしなければなりません。例えば、コンテナを起動後にパッケージをインストールしたりすると、外部の要因によってそのコンテナイメージの実行結果に変化が生じてしまいます。DockerコンテナではDockerfileでバージョン管理ができるため、アプリケーションの実行バイナリや関連リソースは可能な限りDockerイメージ内に埋め込むことがベストプラクティスです。 3番目にDockerイメージをなるべく軽量に保つことです。コンテナ実行時にノード上に使用するDockerイメージをpullして取得する必要があるため、Dockerイメージはなるべく軽量にすることでDockerを使う利点である軽量で高速な起動を最大限に生かすことができます。すぐにできる処置としてはdnf/yumやaptなどでパッケージをインストールした後のキャッシュファイルの削除などです。そのほか、ベースイメージが軽量なイメージを使うことも考えられます。極めていくと、Dockerfileの最適化やsquashなどで軽量化が可能ですが、今回の趣旨から大きくズレるため本記事では省略します。 最後にコンテナ内でプロセスを起動する実行ユーザの権限を最小化することです。 これはLinux運用でも同じですが、Rootユーザの利用はセキュリティ的なリスクが高いので極力控えた方がいいでしょう。 Dockerfileの書き方 DockerイメージはDockerfileを元にビルドされます。Dockerfileというのは以下のようの形式で記述する作成手順書のようなもの。 # どのイメージを基にするか FROM centos # 作成したユーザの情報 LABEL maintainer="Admin <admin@admin.com>" # RUN: docker buildするときに実行される RUN echo "now building..." # CMD: docker runするときに実行される CMD echo "now running..." Dockerfileの基本的な流れとしては、FROMで指定したベースイメージに対してRUNやCOPYなどを用いてパッケージのインストールなどの様々な処理を行いイメージを作成します。 RUNはDockerfileでおそらく最もよく使う命令です。RUN命令はビルド時に実行する命令で、yumやaptコマンドによるパッケージのインストールなどビルド時に必要なコマンドを実行するために用いられます。 それに対して、ENTRYPOINTとCMDはコンテナ起動時に実行するデフフォルトのコマンドを指定するために用います。例えば、ENTRYPOINT=/bin/echo, CMD='Hello'であるとすると、/bin/echo 'hello'が実行されます。要するに、$ENTRYPOINT $CMDが実行されるという認識で問題なさそうです。 そのほかコマンドを実行する作業ディレクトリを指定するWORKDIRやコンテナ起動時のListenポートを指定するEXPOSEなどありますがここでは割愛します。 Dockerイメージのビルド dockerイメージをビルドするコマンドはdocker image buildです。 カレントディレクトリにあるsample:0.1というイメージをビルドする際には、 docker image build -t sampel:0.1 . とします。-tオプションではイメージの名前の指定とタグの指定が行えます。 マルチステージビルド Dockerコンテナの作成に際して注意しなければならないポイントの1つとして”軽量なイメージにする”とありました。マルチステージビルドは複数のコンテナを用いてビルドするコンテナと実行するコンテナを分けることで実行コンテナのイメージサイズを減らす手法です。 以下の例はマルチステージを用いない場合のDockerfileです。 FROM node:lts-alpine WORKDIR /app COPY . ./ RUN npm install -g http-server && \ npm install && \ npm run build EXPOSE 8080 CMD [ "http-server", "dist" ] マルチステージビルドを用いると以下のようになります。 --fileタグを用いてビルド用コンテナから必要なファイルのみを取得することでコンテナのイメージサイズを減らすことができます。 FROM node:lts-alpine AS build-stage WORKDIR /app COPY . ./ RUN npm install && \ npm run build #実行コンテナ FROM nginx:stable-alpine AS production-stage # --fromタグを用いてビルドコンテナから必要なファイルのみをコピーする COPY --from=build-stage /app/dist /usr/share/nginx/html EXPOSE 80 CMD [ "nginx", "-g", "daemon off;" ] Dockerレジストリ DockerレジストリはDockerイメージを保存しておくリポジトリサーバです。 Docker HubやGoogle Container Registry、Amazon ECRなどが有名です。 Docker Hubでは公開されているDockerイメージが置かれています。その中には、「公式イメージ」と「有志が作成した非公式なイメージ」があるため、利用の際には信頼できるイメージなのかどうか注意する必要があります。 基本的には「公式イメージ」を使うことがベストプラクティスです。 しかし、公式の中にもセキュリティアップデートのされていないイメージが含まれていることがあり得ます。 実運用に際してはコンテナのセキュリティスキャンツールを利用することを検討しましょう。 Docker Hubへのプッシュ Docker Hubへのプッシュではまず最初にDockerレジストリへログインする必要があります。以下のコマンドでログインできます。 docker login ユーザ名とパスワードが要求されるのでそれぞれDocker Hubのアカウントのものを入力（なければDocker Hubのページで作成）。 以下のコマンドでプッシュできます。ユーザ名とDockerイメージ名は適切なものを指定してください。 # イメージのタグを付け替える docker image tag sample:0.1 DOCKERHUB_USERNAME/sample:0.1 docker image push DOCKERHUB_USERNAME/sample:0.1 以上でDocker HubのWebページで公開されていることが確認できると思います。 タグ付けについては以下の図が非常にわかりやすいです。 Dockerイメージのタグ付けについては以下のサイトにわかりやすくまとめてありました。 （図もこちらのものを参照しています。） 終わりに 以上でKubernetesを扱う上での最低限のdockerの知識は紹介できました。 Docker自体はまだまだ奥が深く、ここでは紹介しきれない知識がありますが、必要に応じて身につけていきたいですね。

Dockerでfatal error やったこと 以下リンクから、docker 最新バージョン(この時は3.3.3)をダウンロード ドラッグ 起動