Dockerについてあまり理解していなかったので、 自分なりに簡単にまとめていきたいと思います。 今回はWebアプリ構築することを前提に書いていきます。 Dockerとは 仮想環境を構築するためのツールです。 "コンテナ"と呼ばれる仮想環境を構築し、 そのコンテナを組み合わせて動かすことでWebアプリを動かすことができます。 コンテナとは 設定ファイルなどをひとまとめにしたもの。 例えば、 アプリ（laravel、Railsなど）、ミドルウエア（MySQL,Nginxなど） 、OS（CentOS,Ubuntuなど）など様々なコンテナを作ることができます。 Docker意外にも様々な仮想化ソフトが存在します。（図） コンテナを細かく見るとこんな感じです（図） イメージ Dockerコンテナを作るためのためのレシピみたいなものです。 ベースイメージ Docker Hubなどで提供されているベースになるイメージです。 レイヤ レイヤを重ねることでイメージを自分好みにカスタムできます。 Dockerと仮想化ソフト(VirtualBox)の違いは？ 仮想化ソフト(VirtualBox) ■メリット ・細かな設定ができる。 ■デメリット ・ゲストOSを起動しなければならない。Dockerに比べてCPU、メモリを消費する。 Docker ■メリット ・イメージがあれば簡単に環境構築ができる。 ・「作って壊す」がすぐでき、必ず同じ環境が作れる。 ■デメリット ・同一のOSから複数のコンテナを作成するため、違うOSを使いたい場合は別のマシン必要。 家を例にして比較（DockerとVirtualBox） ①土地（ホストOS） 　家を立てるのに土地が必要。 ②家の外装（VirtualBox、Docker Engine） 　家の骨組み、外観を決める。 ③家の内装（Vagrant、Docker） 　Vagrant：内観の設計、部屋を何するかを決める 　　　　　→細かく決めるが設計など時間がかかる。 　Docker：部屋を何するかを決める 　　　　　→部屋をすぐに変更できるが家の細かなカスタムは不向き。

開発環境 docker for mac 環境で動作の遅さを感じるので、 今更ながらvagrantで開発環境を作ってみようと思いました。 やってみてdockerの動作が早くなってびっくりです。 自分の場合だと、vscodeのおかげで開発に支障がでないので、 結果的にやってよかったと思います。 遅いと悩んでいるのであれば、試してみると快適になるかもしれません。 vagrant 環境設定 $ vagrant init $ mkdir source Vagrantfile の中身 # -*- mode: ruby -*- # vi: set ft=ruby : # All Vagrant configuration is done below. The "2" in Vagrant.configure # configures the configuration version (we support older styles for # backwards compatibility). Please don't change it unless you know what # you're doing. Vagrant.configure("2") do |config| # The most common configuration options are documented and commented below. # For a complete reference, please see the online documentation at # https://docs.vagrantup.com. # Every Vagrant development environment requires a box. You can search for # boxes at https://vagrantcloud.com/search. config.vm.box = "bento/ubuntu-20.04" # Disable automatic box update checking. If you disable this, then # boxes will only be checked for updates when the user runs # `vagrant box outdated`. This is not recommended. # config.vm.box_check_update = false # Create a forwarded port mapping which allows access to a specific port # within the machine from a port on the host machine. In the example below, # accessing "localhost:8080" will access port 80 on the guest machine. # NOTE: This will enable public access to the opened port # config.vm.network "forwarded_port", guest: 80, host: 8080 # Create a forwarded port mapping which allows access to a specific port # within the machine from a port on the host machine and only allow access # via 127.0.0.1 to disable public access # config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1" # Create a private network, which allows host-only access to the machine # using a specific IP. # config.vm.network "private_network", ip: "192.168.33.10" # Create a public network, which generally matched to bridged network. # Bridged networks make the machine appear as another physical device on # your network. # config.vm.network "public_network" # Share an additional folder to the guest VM. The first argument is # the path on the host to the actual folder. The second argument is # the path on the guest to mount the folder. And the optional third # argument is a set of non-required options. config.vm.synced_folder "./source", "/home/vagrant/shareMacSource" # Provider-specific configuration so you can fine-tune various # backing providers for Vagrant. These expose provider-specific options. # Example for VirtualBox: # config.vm.provider "virtualbox" do |vb| vb.gui = false vb.memory = "8192" vb.cpus = 4 end # # View the documentation for the provider you are using for more # information on available options. # Enable provisioning with a shell script. Additional provisioners such as # Ansible, Chef, Docker, Puppet and Salt are also available. Please see the # documentation for more information about their specific syntax and use. # config.vm.provision "shell", inline: <<-SHELL # apt-get update # apt-get install -y apache2 # SHELL end vagrant で 8080 とかで動かす時、この設定をよしなに変更することで、 mac でも localhost:8080 で接続することができる。 # config.vm.network "forwarded_port", guest: 80, host: 8080 vagrant ssh-config を実行して ssh/config に追記する内容を出力する Host develop HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile < youre privater ssh-key path> IdentitiesOnly yes LogLevel FATAL vagrant に ssh で接続 $ ssh develop --- vagrant@vagrant:~$ sudo passwd vagrant new password: Retype new password: ※入力したパスワードは非表示 nano から vim に変更 $ sudo update-alternatives --set editor /usr/bin/vim.basic Docker インストール 公式ドキュメントのコマンドをコピペする Ubuntu 20.04へのDockerのインストールおよび使用方法 | DigitalOcean $ sudo apt-get update $ sudo apt install -y apt-transport-https ca-certificates curl software-properties-common $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable" $ sudo apt update $ apt-cache policy docker-ce $ sudo apt install -y docker-ce $ sudo systemctl status docker $ sudo usermod -aG docker ${USER} -- ここでsshを切断し、再度接続 -- $ id -nG vagrant@vagrant:~$ id -nG vagrant adm cdrom sudo dip plugdev lxd lpadmin sambashare docker -- docker が追加されている --- docker コマンドが実行できるか確認 $ docker run hello-world ログインシェルを fish に変更 $ sudo apt-add-repository ppa:fish-shell/release-3 $ sudo apt-get update $ sudo apt-get install -y fish $ which fish > /usr/bin/fish $ sudo vi /etc/shells ※ fish のパスが追加されていることを確認（追加されていない場合は追記） デフォルトシェルの変更 $ chsh -s /usr/bin/fish Password: fish プラグインをインストール $ fisher install jethrokuan/z $ fisher install jethrokuan/fzf $ fisher install decors/fish-ghq 便利コマンドを追加 ディレクトリ構造 .config/fish ├── config.fish └── functions ├── peco_change_history.fish └── peco_exploer_directory.fish config.fish ### ショートカットを追加 # peco shortcut key function fish_user_key_bindings # Bind for peco show history to Ctlr+h bind \ch peco_change_history # Bind for prco change directory to Ctrl+f bind \cf peco_exploer_directory end pecho_change_history.fish function peco_change_history if test (count $argv) = 0 set peco_flags --layout=bottom-up else set peco_flags --layout=bottom-up --query "$argv" end history|peco $peco_flags|read foo if [ $foo ] commandline $foo else commandline '' end end peco_exploer_directory.fish function peco_exploer_directory set -l query (commandline) if test -n $query set peco_flags --query "$query" end z -l | peco $peco_flags | awk '{ print $2 }' | read recent if [ $recent ] cd $recent commandline -r '' commandline -f repaint end end ホームディレクトリで vagrant コマンドが実行できるようにする ※ vagrant を使わない想定なのでこれでOK 開発環境は develop に集約してそこで docker とか動かしたい $ direnv edit . export VAGRANT_CWD=<Vagrantfile があるディレクトリを指定> # 環境変数の有効化 $ direnv allow # vagrant コマンドを指定し、path指定したvagrant を操作できればOK $ vagrant status Current machine states: default running (virtualbox) まとめ docker for mac が遅くネイティブレベルの早さを手に入れたいと思い、 思い切って vagrant に開発環境を作ってみました。 macしかできないことは普段やらないので、メインPCをLinuxにするか悩み中です。

DockerのWordPressイメージを公開します。 もし有用なら、GitHub や Docker hub で星を付けて頂けると励みになります。 https://github.com/takeyamajp/docker-wordpress このDockerイメージを使って、いつでも完成度の高いWordPress環境を気軽に作り出す事ができます。 サイト構築やプラグインのテスト環境として最適です。 また、個人レベルの小規模サイトであれば実運用にも耐えられます。 関連するDockerイメージとして、データベース用のMySQL, MariaDB, phpMyAdminなどのイメージも公開しています。 https://github.com/takeyamajp/docker-mysql https://github.com/takeyamajp/docker-mariadb https://github.com/takeyamajp/docker-phpmyadmin また、WordPressで使用する送信専用メールサーバーには以下のDockerイメージがお勧めです。 https://github.com/takeyamajp/docker-postfix https://qiita.com/takeyamajp/items/be4ccc61862de3b121bf 概要 このDockerイメージには、以下のような特徴があります。 ・タイムゾーンを設定する事ができる。 ・httpをhttpsに自動リダイレクトさせる事ができる。 ・GZIP圧縮をサポートしている。 ・BASIC認証をサポートしている。 ・WordPressの基本設定を、このDockerイメージの変数から行う事ができる。 ・php-fpmで動作する。 FROM centos:centos8 ... ENV TIMEZONE Asia/Tokyo ENV FORCE_SSL true ENV GZIP_COMPRESSION true ENV BASIC_AUTH false ENV BASIC_AUTH_USER user ENV BASIC_AUTH_PASSWORD password ENV HTTPD_SERVER_ADMIN root@localhost ENV HTTPD_LOG true ENV HTTPD_LOG_LEVEL warn ENV HTTPD_PHP_ERROR_LOG true ENV WORDPRESS_DB_HOST mysql ENV WORDPRESS_DB_NAME db ENV WORDPRESS_DB_USER user ENV WORDPRESS_DB_PASSWORD password ENV WORDPRESS_TABLE_PREFIX wp_ ENV WORDPRESS_DEBUG false ENV WORDPRESS_CONFIG_EXTRA param1,param2 ENV WORDPRESS_CONFIG_EXTRA_VALUE \'string\',true VOLUME /wordpress EXPOSE 80 EXPOSE 443 実行方法 最もシンプルな実行方法を紹介します。 以下のymlファイルを作成してDocker-Composeで実行してください。 （takeyamajp/mysqlの部分は、takeyamajp/mariadbに置き換えることができます。） その後、任意のブラウザーからhttp://localhost:8080/、もしくはhttp://サーバーのIPアドレス:8080/にアクセスしてください。 （MySQLやMariaDBの初期化処理に数十秒～数分間待つ必要があります。） docker-compose.yml version: '3.1' services: wordpress: image: takeyamajp/wordpress ports: - "8080:80" environment: FORCE_SSL: "false" mysql: image: takeyamajp/mysql 各種設定 タイムゾーン（TIMEZONE） サイトで扱われる日時のタイムゾーン設定です。 Linuxで設定可能なタイムゾーンをそのまま設定する事ができます。 日本国内で使用する場合は、設定を変更する必要はありません。 SSL通信の強制（FORCE_SSL） httpでアクセスした場合に、自動的にhttpsにリダイレクトする設定です。 簡易のテスト環境を用意する場合など、このDockerイメージを単体で動作させるときは、上記のdocker-compose.ymlファイルのようにfalseに設定してください。 リバースプロキシのバックエンドとして動作させる場合はtrueに設定してください。 （リバースプロキシとhttps通信するためにイメージ内に自己署名のSSL証明書を自動作成します。） GZIP圧縮（GZIP_COMPRESSION） サイトの表示速度を向上させるために、GZIP圧縮を有効にする設定です。 通常は設定を変更する必要はありません。 BASIC認証（BASIC_AUTH） 一部の人だけがサイトにアクセスできるようにBASIC認証をかける事ができます。 前述のFORCE_SSLがtrueになっている場合は、先にhttpsにリダイレクトされた後にBASIC認証が要求されるため、ネット上で認証情報を平文でやりとりする事はありません。 サーバーの管理者情報（HTTPD_SERVER_ADMIN） サーバー上でエラーが発生した場合に、エラーページに表示する問い合わせ先情報です。 本番運用する場合は、連絡先のメールアドレスを設定してください。 https://httpd.apache.org/docs/2.4/ja/mod/core.html#serveradmin サーバーのログ出力 このDockerイメージで出力されるログは、すべてDocker logsに出力します。 次のコマンドdocker logs -f wordpressを実行すると、出力されるログをリアルタイムで確認する事ができます。 HTTPD_LOG WEBサーバーのログ出力をするかどうかの設定です。 通常は変更する必要はありません。 出力内容を増減させたい場合は、後述するHTTPD_LOG_LEVELを変更してください。 HTTPD_LOG_LEVEL WEBサーバーのログ出力レベルを８段階で設定します。 通常は変更する必要はありません。 https://httpd.apache.org/docs/2.4/ja/mod/core.html#loglevel HTTPD_PHP_ERROR_LOG PHPプログラムでエラーが発生した場合にログ出力するかどうかの設定です。 WordPress、プラグインなどでエラーが発生した場合にログが出力されます。 通常は変更する必要はありません。 WordPressのデータベース設定 ここで事前にデータベース設定をしておけば、初回起動時にデータベースの接続情報を手入力する必要はありません。 WORDPRESS_DB_HOST データベースのホスト名（Dockerのコンテナ名）を設定します。 WORDPRESS_DB_NAME データベース名を設定します。 データベースのコンテナと設定を合わせる必要があります。 WORDPRESS_DB_USER データベースのユーザー名を設定します。 データベースのコンテナと設定を合わせる必要があります。 WORDPRESS_DB_PASSWORD データベースユーザーのパスワードを設定します。 データベースのコンテナと設定を合わせる必要があります。 WORDPRESS_TABLE_PREFIX データベースのテーブル名で使用される接頭辞です。 通常は設定を変更する必要はありません。 １つのデータベースに２つ以上のWordPressデータを保存するときに、WordPressのコンテナ毎に設定を変えてください。 WordPressの追加設定 wp-config.phpに自動追加される設定です。 多くの場合、手動でWordPressの設定ファイルを編集する必要は無いでしょう。 例えば、サンプルとして用意されているデフォルト設定では、wp-config.phpの先頭に以下の行が自動追加されます。 // BEGIN CONFIG EXTRA define('param1', 'string'); define('param2', true); // END CONFIG EXTRA WORDPRESS_CONFIG_EXTRA カンマ区切りでパラメータ名を設定します。 WORDPRESS_CONFIG_EXTRA_VALUE カンマ区切りでパラメータの値を設定します。 文字列を設定する場合は、カンマ文字をエスケープしてください。 WordPressのデータを永続化する。 必要に応じて、任意のディレクトリをボリューム/wordpressにマウントしてください。 新規の環境を構築する場合は、空ディレクトリをマウントしてください。 既存のWordPressディレクトリをマウントする事で、他の環境からファイルデータを引き継ぐ事ができます。 WordPressのデバッグ設定 WORDPRESS_DEBUG WordPress自体のデバッグを行う場合にtrueに設定してください。 通常は使用しません。 — 以上です。 それでは良いWordPressライフを。

想定読者 Dockerは使ったことあるけど、Dockerfileを真面目に書いたことはない方 気にすべきことを1つでも知っておきたいと思っている方 気をつけなきゃと思ったこと 1. コマンドの微妙な違いを理解しておく 1.1　RUN cd <dir> と WORKDIR <dir> 　どちらも作業ディレクトリを指定するという意味では同じですが、微妙な違いを認識しておらず少しハマりました。 例えば、centosのベースイメージにnginxをソースからビルドしてインストールする場合、深く考えずに Dockerfile(抜粋) RUN cd /usr/local/src RUN curl -O https://nginx.org/download/nginx-1.18.0.tar.gz RUN tar xvzf nginx-1.18.0.tar.gz RUN cd nginx-1.18.0 RUN ./configure RUN make RUN make install のようにかいて docker build しようとすると、 /bin/sh: ./configure: No such file or directory となります。 はじめは、curlでファイル取れてない？tarで解凍失敗した？などなど考え検証するのですが、実際には4行目で /nginx-1.18.0 に移動できていないことが原因だったりします。 RUN cd nginx-1.18.0とだけ書いてしまうと、/nginx-1.18.0を一瞬覗いただけで実際には移動しておらず、その後のコマンドはカレントディレクトリで実行されてしまうため、./configureなんてないよ、と言われているという次第です。なので一行目のcdも機能しておらず、結果的に全てのコマンドが/で実行されている形になっています。 こんなときに、WORKDIRを用いて、 Dockerfile(抜粋) WORKDIR /usr/local/src RUN curl -O https://nginx.org/download/nginx-1.18.0.tar.gz RUN tar xvzf nginx-1.18.0.tar.gz WORKDIR /usr/local/src/nginx-1.18.0 RUN ./configure RUN make RUN make install のようにに書きかえてあげるとちゃんとディレクトリを渡り歩いてうまく動いてくれます1。 ちなみに、RUN cdを使って4行目以降を RUN cd /usr/local/src/nginx-1.18.0 && ./configure && make && make install のように書くこともできます。 というか、イメージ容量削減の観点では後者の方が望ましいようです。(説明は3.2にて) 1.2　ARG と ENV 変数を定義するという意味では同じですが、ARGは頻繁には使われないイメージです。違いは以下。 ENV　→　コンテナ内に定義される環境変数 ARG　→　Dockerfile内でのみ使用できる変数 私は ARG は主に、 Dockerfile(抜粋) ARG NGINX_VERSION RUN curl -O https://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz docker build --build-arg NGINX_VERSION=1.18.0 --tag=sample_image:sample_tag のようにビルド時に --build-arg で渡したバージョンをDockerfile内で参照する形で使っています。 1.3　VOLUME とdocker run -v これは、Dockerfileのコマンドというより、Dockerのマウントの種類の違いに関するものなので少し逸れますが、若干ハマったのでメモ的に記載します。マウントの種類とその違いについては各自調査いただければと思います。 　Dockerfile内に VOLUME <path> とかくと、docker run -v <path>:<path> と書いたのと同等なのかと思っていましたが、前者は マウントの種類のうち「(Docker)ボリューム」によるマウントで、後者は「バインドマウント」によるマウントであって、挙動が異なるということを書いておきます。(詳細は長くなりそうなので別記事で書くかもしれません。) 2. 認証情報等をイメージに残さないようにする 社内環境でDockerを使うととにかくプロキシの壁にはまります。 docker build しようとしたら、初っ端からエラー　=>　ビルド時にプロキシ認証情報を渡す yum install / wget / curlしようとしたら名前解決エラー　=>　プロキシ認証情報を設定ファイルに書き込んでから実行2 or 実行時に引数で渡す3 などなど。 ビルドするときだけでこれだけプロキシ認証情報を入れ込むタイミングがあるので、気をつけないとイメージの中のどこかに残ったままになってしまう恐れがあります。考えられるbetterな対応としては、 ビルド時にプロキシ認証情報を渡すとき docker build --build-arg HTTP_PROXY=${HTTP_PROXY} --build-arg HTTPS_PROXY=${HTTPS_PROXY} --tag=sample_image:sample_tag のように、ホストに事前に設定した環境変数HTTP_PROXY, HTTPS_PROXYを--build-argで渡す4 プロキシ認証情報を設定ファイルに書き込んだ場合 Dockerfileのなかで、書き込んだプロキシ情報をsedなどで一通り削除しておく4 3. イメージの容量がなるべく軽くなるようにする 3.1　なるべくオフィシャルイメージを使う オフィシャルイメージは熟練者が書いたDockerfileで作られており無駄がないので、特別な理由がない限りはオフィシャルイメージを使うことをおすすめします。 以下は、nginx(latest)のイメージを例にイメージを比較した表です。 容量 ベースイメージ nginxインストール方法 Official Image 126 MB debian:buster-slim 不要 自作1 328 MB centos 8 yum install nginx 自作2 487 MB centos 8 ソースからビルド 「現実にはcentosあたりをベースに自作するケースが多いのでは」という仮説から自作のものはcentos 8をベースにしているので熟練者の削減術の成果がわかるものではありません。あくまで参考数値とご認識ください。centosはalpineやdebianと比べるとだいぶ容量をとるようですね。 3.2　RUNコマンドは極力まとめる 依存ライブラリがたくさんあるときに、 Dockerfile(抜粋) RUN yum install -y gcc RUN yum install -y pcre pcre-devel RUN yum install -y zlib zlib-devel RUN yum install -y openssl openssl-devel RUN yum install -y make のように一つ一つRUN する形で書くと、その都度イメージのレイヤが追加されてイメージの容量の増加に繋がってしまうようです。こういうときは、 Dockerfile(抜粋) RUN yum install -y gcc \ && yum install -y pcre pcre-devel \ && yum install -y zlib zlib-devel \ && yum install -y openssl openssl-devel \ && yum install -y make のように一つの RUN でまとめてみましょう。 3.3　マルチステージビルドを活用する Vue.js アプリケーションを Docker 化する にあるように、1つのDockerfileの中で アプリのビルドイメージ作成ステージ ビルド成果物デプロイ用イメージ作成ステージ のように複数のステージを定義し連携することで、アプリのビルド時のみ必要であったファイル等を最終的なイメージに含めなくて済み、イメージの軽量化につながるというものです。 そのほかにも、イメージの軽量化につながる工夫が公式ページ(以下)等にたくさん書かれているので、Dockerfileの熟練者を目指す方は熟読と実践をしてみていただければと思います。 終わりに Dockerはなかなか慣れるまで時間がかかります。次はdocker-composeについてかけたらと思います。 本題から逸れるので省きましたが、実際にはこの前にここに記載のある依存ライブラリ(とgccとmake)のインストール処理が必要です。 ↩ yum → /etc/yum.conf, wget → ~/.wgetrc, curl → ~/.curlrc ↩ wget → -e http_proxy={プロキシ認証情報}, curl → -x {プロキシ認証情報} (yumの場合は --setopt=proxy={プロキシ認証情報}でできるとの情報もあるが動作未確認) ↩ これで完全にプロキシ認証情報が残らないと言い切れるほど検証ができておりませんゆえ、その点ご容赦ください。 ↩

はじめに Docker上にLaravel環境を作成して開発をしていました。 なんてことないリクエストの処理に10秒程度かかることもあり、原因を調べてみたところDockerの設定に問題があるようなので対策をしました。 環境 Windows 10 Docker for Windows PHP 8.0.3 Laravel 8.5.15 ディレクトリ構成 . ├── app # アプリケーションのソース(Laravel) ├── docker-compose.yml └── infra # Dockerfile等の設定ファイル 原因 ホスト側のvendorディレクトリをマウント(バインドマウントと言うらしい)しているのが原因でした。 対策 名前付きボリュームを利用します。 docker-compose.yml version: '3.5' services: php: build: ./infra/php image: performance_test_fast container_name: performance_test_fast environment: VIRTUAL_HOST: 'fast.localhost' CERT_NAME: 'localhost' volumes: - ./app:/var/www/html - ./infra/apache/000-default.conf:/etc/apache2/sites-enabled/000-default.conf - vendor-store:/var/www/html/vendor # 追加 networks: - performance-fast-network - proxy-network networks: performance-fast-network: name: performance-fast-network proxy-network: external: true name: proxy-network volumes: # 追加 vendor-store: # 追加 結果 目で見てわかるレベルで速度が改善されました。 改善前 改善後 5100ms 137ms 最後に 今までとりあえず動けばいいやという感覚で設定していたので、これを機にDockerの設定ファイルの見直しをしていきたいと思います。 間違いや改善点があればコメントにて教えていただければ幸いです。 参考 ボリュームの利用 Docker の Volume がよくわからないから調べた Docker Composeのvolumesを使ってもっと効率的に

はじめに 概要 Docker と VSCode Remote Container による Go の Web サーバ開発環境を構築する記事です。 ローカルに Go をインストールすることなく、 コード補完 コード変更があるたびに再ビルド（ライブリロード） の Go 開発環境を構築します。 リポジトリ この記事で作成する内容は GitHub に上げています。 背景 業務で Go を触ることとなり、勉強するにあたって手軽な Go の開発環境の構築方法を調べていました。 Docker を使った Go の開発環境を構築する方法はいくつか情報があったのですが、コード補完やフォーマッタを効かせるために結局ローカルに Go をインストールする必要があり、少し微妙でした。 また、簡単な Web サーバを書いていたのですが、ソースコードを修正するたびにいちいちビルドし直すのが面倒でした。 色々と試している中で、 ローカルに Go を入れないといけない問題: VSCode の拡張機能 Remote Container いちいちビルドし直す問題： Go のパッケージ Air で解決できることが分かり、本記事はその成果物です。 できるだけ手軽に、Go の Web サーバ開発環境を整えたい人向けの記事となっています。 開発環境の構築 ディレクトリ構造 . | ├── .devcontaier/ | └── devcontainer.json ├── .air.toml ├── docker-compose.yml └── Dockerfile コンテナ設定 Dockerfile FROM golang:1.16.3-alpine ENV GO111MODULE on WORKDIR /go/src/app RUN apk update \ && apk add git \ && go install github.com/cosmtrek/air@latest \ && go get -u golang.org/x/tools/gopls \ github.com/ramya-rao-a/go-outline ここでは、Go 拡張機能で使用する ranguage server に必要な gopls や、ライブリロードに必要な Air のバイナリインストール＆ビルドを行っています。 docker-compose.yml version: "3.8" services: web: build: context: . dockerfile: Dockerfile command: "air" tty: true stdin_open: true command: "air" volumes: - ./app:/go/src/app ports: - 8080:8080 security_opt: - apparmor:unconfined cap_add: - SYS_PTRACE ライブリロード設定 .air.toml で、ライブリロードの設定を行います。 今回は、公式のサンプルコードをそのまま拝借して使用します。 コンテナ接続設定 VSCode Remote Container 用の設定をします。 .devcontainer/.devcontainer.json { "name": "Go-Practice", "dockerComposeFile": [ "../docker-compose.yml", ], "service": "web", "workspaceFolder": "/go/src/app", "settings": { "terminal.integrated.shell.linux": "/bin/ash", "go.toolsManagement.checkForUpdates": "off", "go.gopath": "/go", "go.gocodeAutoBuild": true, "go.formatTool": "gofmt", "go.useLanguageServer": true, "editor.formatOnSave": false, "[go]": { "editor.formatOnSave": true } }, "extensions": [ "golang.go" ], } extensionsの部分で、ワークスペースに任意の VSCode 拡張をインストールすることができます。今回は、最低限の設定として Go の VSCode 拡張を入れています。 他にも、今回は軽量なalpineイメージを使用するので、 "terminal.integrated.shell.linux": "/bin/ash", の部分でワークスペースで使用するシェルにashを指定しています。 alpineでもbashを使いたい方は、イメージビルド時に bash を入れたりするなど、適宜カスタマイズしてください。 開発環境の起動 Docker イメージのビルド docker-compoase build コンテナの立ち上げ docker-compose up -d docker-compose logs -f webでコンテナのログを見ると、ライブリロードのairが立ち上がっていることがわかります。 web_1 | __ _ ___ web_1 | / /\ | | | |_) web_1 | /_/--\ |_| |_| \_ // live reload for Go apps, with Go web_1 | 開発コンテナ接続 Remote Container でコンテナに接続する方法はいくつかあります。以下のうちどれかを行います。（どれでもいい） 以下、全て VSCode での作業 [Cmd + Shift + P] > [reopen in container]を選択 VSCode の左下にある >< を押す > [reopen in container]を選択 左側のアイコン(Remote Explerer) > Containers > 該当のコンテナを選択 Docker のコンテナ内で、VSCode を開くことができました。 コーディングしてみる Go コンテナの中に入ることができたので、とりあえず Gin で Web サーバーを立てて動作を確認します。 パッケージのインストール ash go mod init プロジェクト名 で go.mod を作成したら、 ash go get -u github.com/gin-gonic/gin でginをインストール。 サーバー立ち上げ ash touch main.go main.go package main import "github.com/gin-gonic/gin" func main() { r := gin.Default() r.GET("/ping", func(c *gin.Context) { c.JSON(200, gin.H{ "message": "pong", }) }) r.Run() // listen and serve on 0.0.0.0:8080 (for windows "localhost:8080") } 動作確認 localhost:8080/ping { "message": "pong" } ちゃんと動いてそうです。 ライブリロードの確認 コードを少し変更してみます。 main.go package main import "github.com/gin-gonic/gin" func main() { r := gin.Default() r.GET("/ping", func(c *gin.Context) { c.JSON(200, gin.H{ "message": "pong", }) }) + r.GET("/hoge", func(c *gin.Context) { + 　　 c.JSON(200, gin.H{ + "message": "fuga", + }) + }) r.Run() // listen and serve on 0.0.0.0:8080 (for windows "localhost:8080") } 再度動作確認 web_1 | main.go has changed web_1 | building... web_1 | running... web_1 | [GIN-debug] GET /ping --> main.main.func1 (3 handlers) web_1 | [GIN-debug] GET /hoge --> main.main.func2 (3 handlers) localhost:8080/hoge { "message": "fuga" } ちゃんと変更が反映されていることがわかります。 おわりに 手軽な Go の開発環境構築として、Docker・Air・VSCode Remote Container を使用する方法を紹介させていただきました。 「DB コンテナも使いたい」となったらdocker-compose.ymlに DB コンテナの記述を加えたり、「もっといろいろワークスペースをカスタマイズしたい」となったら拡張機能をワークスペースに入れたりなど、色々と柔軟に拡張できると思います。 最後に、メリットデメリットをまとめておきます。 本記事で紹介する環境のメリット/デメリット メリット Docker, VSCode があれば作れる ローカルに Go をインストールせずに、コード補完等のサポートが効く コードを変更すると、自動でソースコードをリビルドしてくれる docker コマンドをいちいち流さなくても良い デメリット git 管理の構成を考えるのが難しい 1 コンテナにつき開ける VSCode のウィンドウが一つ 何らかのポートを開けっぱなしにするとき、VSCode のデバッグが使えない メリットもある一方、デメリットも多くあるなぁと筆者自身感じています。特にデバッグ構成については、Web サーバの開発であればライブリロードと相性が悪いです。 （以下、デバッグと Air が共存できない例） 変更があるたびにソースコードがビルドされ、ポート:8080で Gin の Web サーバが立ち上がっている。 ここで、VSCode でデバッグを行うと、デバッグのためにソースコードがビルドされる。 デバッグでのビルド時、同じくポート:8080で Gin をサーバを立ち上げようとするため、ポートの競合が発生し、デバッグモードにできない。 こちらについては、未だベストな解決方法が思いついておりません。結局、ライブリロードをやめてデバッグモードでの開発が良いのかなと思っています。 以上のメリット・デメリットを踏まえた上で、今回の環境構築を試していただければと思います。 もっと良い方法があるよ！等ありましたら、是非教えていただきたいです ?‍♂️ 参考資料

背景と目的 2021年4月現在、.NET 6 Preview は App Service でサポートされていませんが、Web App for Container なら .NET 6 Preview を動かすことが可能なのではないかと思い、試してみました。 前提条件 .NET 6 環境は、.Net 6.0.0 Preview 2 を Visual Studio Code から Docker 利用してみた で作成した環境を使用します。 その他コマンドの実施環境は、Mac + Azure CLI です。 zsh % sw_vers ProductName: macOS ProductVersion: 11.2.3 BuildVersion: 20D91 % az version { "azure-cli": "2.21.0", "azure-cli-core": "2.21.0", "azure-cli-telemetry": "1.0.6", "extensions": {} } 実施内容 VSCode の .NET 6 環境で MVC アプリを作成して動作確認を行います。 bash $ docker new mvc -n mvcapp $ cd mvcapp $ cat << EOF > Views/Home/Index.cshtml @using System.Runtime.InteropServices @{ ViewData["Title"] = "Home"; } <div class="text-center"> <h5>Environment</h5> <p>@RuntimeInformation.FrameworkDescription (@RuntimeInformation.ProcessArchitecture)</p> <p>@RuntimeInformation.OSDescription</p> </div> EOF $ dotnet run # http://localhost:5000 をブラウザで確認します。 # 問題なkれば、Ctrl+C で終了します。 $ dotnet publish -c Release $ ls -l bin/Release/net6.0/publish/ VSCode の Docker 環境から抜けて、上で作成した mvcapp ディレクトリまで移動して Mac 上で作業します。 zsh % cat <<EOF > Dockerfile FROM mcr.microsoft.com/dotnet/aspnet:6.0 COPY bin/Release/net6.0/publish/ App/ WORKDIR /App ENTRYPOINT ["dotnet", "mvcapp.dll"] EOF % az group create \ --name AppSvc-DockerTutorial-rg \ --location japaneast % az acr create \ --name mnrappsvc \ --resource-group AppSvc-DockerTutorial-rg \ --sku Basic \ --admin-enabled true # いつもなら下記コマンドで ACR へイメージをプッシュしますが、今回はもっと簡単に az acr build を使用します。 # docker login mnrappsvc.azurecr.io \ # --username mnrappsvc \ # --password $(az acr credential show \ # --resource-group AppSvc-DockerTutorial-rg \ # --name mnrappsvc \ # --query "passwords[0].value" \ # --output tsv) # docker build --tag mvcapp . # docker tag mvcapp mnrappsvc.azurecr.io/mvcapp:latest # docker push mnrappsvc.azurecr.io/mvcapp:latest % az acr build \ --file Dockerfile \ --registry mnrappsvc \ --image mvcapp . % az appservice plan create \ --name AppSvc-DockerTutorial-plan \ --resource-group AppSvc-DockerTutorial-rg \ --is-linux % az webapp create \ --resource-group AppSvc-DockerTutorial-rg \ --plan AppSvc-DockerTutorial-plan \ --name mnrappsvc \ --deployment-container-image-name mnrappsvc.azurecr.io/mvcapp:latest % az webapp identity assign \ --resource-group AppSvc-DockerTutorial-rg \ --name mnrappsvc % az role assignment create \ --assignee $(az webapp identity show \ --resource-group AppSvc-DockerTutorial-rg \ --name mnrappsvc \ --query principalId \ --output tsv) \ --scope $(az acr show \ --name mnrappsvc \ --resource-group AppSvc-DockerTutorial-rg \ --query id \ --output tsv) \ --role "AcrPull" % curl $(az webapp show \ --name mnrappsvc \ --resource-group AppSvc-DockerTutorial-rg \ --query defaultHostName \ --output tsv) # リソースをクリーンアップする % az group delete \ --name AppSvc-DockerTutorial-rg 実施結果 .NET 6 Preview を App Service で動かすことが出来ました！ 参考 Running .NET 6 (Preview) on App Service カスタム コンテナーを使用してカスタム ソフトウェアを Azure App Service に移行する チュートリアル: NET Core アプリのコンテナー化 ASP.NET Core 向けの Docker イメージ

Flask とPyJWTを使用してGoogleとのOpenID連携するためのAPI作成方法についてメモする。 連携処理をバックエンド側に持たせたかったため、Docker起動できる形で過去に作成した検証コードをAPI化した。 作成するAPI 認可リクエスト作成API Googleへの認可エンドポイントへアクセスするためのURLをパラメータをつけて生成・返却する。 state,nonceはAPI呼び出し時に生成し、レスポンスとして返却する。 client_idなど固定の属性値は環境変数から取得する。 リクエスト例 POST /api/google/auth_request/create HTTP/1.1 Host: localhost:5000 レスポンス例 { "authorization_request_url": "https://accounts.google.com/o/oauth2/v2/auth?client_id=ABC12345&scope=hoge&redirect_uri=http%3A%2F%2Flocalhost%3A5000%2Fcallback&state=ABCDE12345&nonce=FGHIJ67890&response_type=code", "nonce": "FGHIJ67890", "state": "ABCDE12345" } トークンリクエスト+ユーザー情報取得API 認可レスポンスとして受け取った認可コードを指定して、トークンリクエスト＋id_token検証(ユーザー情報取得)を行う。 今回は簡略化のため認可リクエストパラメータのDB保存までは実装しておらず、検証処理は行っていないが、stateパラメータの検証は必須。 リクエスト例 POST /api/google/auth_request/complete HTTP/1.1 Host: localhost:5000 Content-Type: application/json Content-Length: 173 { "code":"XXXXX", "nonce":"FGHIJ67890" } レスポンス例 { "email": "test@example.com", "email_verified": true, "sub": "123456789123456789" } プロジェクト構成 google_oidc └─ docker-compose.yml └─ google.env │ └─ be └─ Dockerfile └─ requirements.txt │ └─app └─ app.py │ └─ api └─ __init__.py │ └─views └─ google.py 実装 docker-compose.yml ※起動時に環境変数ファイルgoogle.envを読み込む。 version: "3" services: be: container_name: be build: ./be env_file: google.env volumes: - ./be/app:/app ports: - "5000:5000" command: flask run --host 0.0.0.0 --port 5000 tty: true google.env 環境変数ファイル。アプリケーション登録時に発行・設定した値を指定する。 CLIENT_ID=YOUR_CLIENT_ID CLIENT_SECRET=YOUR_CLIENT_SECRET REDIRECT_URI=YOUR_REDIRECT_URI AUTHORIZATION_ENDPOINT=https://accounts.google.com/o/oauth2/v2/auth TOKEN_ENDPOINT=https://www.googleapis.com/oauth2/v4/token SCOPE_LIST=YOUR_SCOPE_LIST ISSUER=https://accounts.google.com be/requirements.txt Pythonライブラリ一式 Flask Flask-Cors PyJWT cryptography be/Dockerfile FROM python:3.8 RUN mkdir /app ADD requirements.txt /app ENV PYTHONUNBUFFERED 1 EXPOSE 5000 WORKDIR /app RUN pip3 install -r requirements.txt be/app/app.py from api import app if __name__ == '__main__': app.run() be/api/__init__.py from flask import Flask from .views.google import google_router from flask_cors import CORS def create_app(): app = Flask(__name__) CORS(app, supports_credentials=True) app.register_blueprint(google_router, url_prefix='/api') return app app = create_app() be/api/views/google.py コントローラー id_token検証用の署名情報は、事前にid_tokeの形式を確認し、コード中にべた書きしている。 import hashlib from flask import Flask, Blueprint, request import urllib.parse as parse import urllib.request as req import urllib.error as error import json import os import jwt from jwt.algorithms import RSAAlgorithm from pprint import pprint # Routing Settings google_router = Blueprint('google_router', __name__) # Client Param client_id = os.getenv('CLIENT_ID') client_secret = os.getenv('CLIENT_SECRET') redirect_uri = os.getenv('REDIRECT_URI') scope_list = os.getenv('SCOPE_LIST') # Google Endpoint authorization_endpoint = os.getenv('AUTHORIZATION_ENDPOINT') token_endpoint = os.getenv('TOKEN_ENDPOINT') # id_token Validation Param issuer = os.getenv('ISSUER') # https://www.googleapis.com/oauth2/v3/certs jwk_json = { "e": "AQAB", "use": "sig", "n": "q_GoX7XASWstA7CZs3acUgCVB2QhwhupF1WZsIr6FoI-DpLaiTlGLzEJlkLKW2nthUP35lqhXilaInOAN86sOEssz4h_uEycVpM_xLBRR-7Rqs5iXype340JV4pNzruXX5Z_Q4D7YLvm2E1QWivvTK4FiSCeBbo78Lpkr5atiHmWEcLENoquhEHdpij3wppdDlL5eUAy4xH6Ait5IDe66RehBEGfs3MLnCKyGAPIammSUruV0BEmUPfecLoXNhpuAfoGs3TO-5CIt1jmaRL2B-A2UxhPQkpE4Q-U6OJ81i4nzs34dtaQhFfT9pZqkgOwIJ4Djj7HI1xKOmoExMCDLw", "kid": "774573218c6f6a2fe50e29acbc686432863fc9c3", "kty": "RSA", "alg": "RS256" } public_key = RSAAlgorithm.from_jwk(jwk_json) app = Flask(__name__) # Create Authorization Request Endpoint @google_router.route("/google/auth_request/create", methods=['POST']) def create(): # Generate nonce and state nonce = hashlib.sha256(os.urandom(32)).hexdigest() state = hashlib.sha256(os.urandom(32)).hexdigest() # Create Authz Request URL auth_request_url = authorization_endpoint+'?{}'.format(parse.urlencode({ 'client_id': client_id, 'scope': scope_list, 'redirect_uri': redirect_uri, 'state': state, 'nonce': nonce, 'response_type': 'code' })) res_body = { "authorization_request_url": auth_request_url, "state": state, "nonce": nonce } return json.loads(json.dumps(res_body)) # Token Request And Get User Info Endpoint @google_router.route("/google/auth_request/complete", methods=['POST']) def complete(): # Parse Req Body jsonData = json.dumps(request.json) req_body = json.loads(jsonData) # Token Request token_req_body = parse.urlencode({ 'code': req_body["code"], 'client_id': client_id, 'client_secret': client_secret, 'redirect_uri': redirect_uri, 'grant_type': 'authorization_code' }).encode('utf-8') token_req = req.Request(token_endpoint) err_str = '' try: with req.urlopen(token_req, data=token_req_body) as f: token_res = f.read() except error.HTTPError as err: err_str = str(err.code) + ':' + err.reason + ':' + str(err.read()) pprint(err_str) except error.URLError as err: err_str = err.reason pprint(err_str) # id_token Validation by PyJWT id_token = json.loads(token_res)['id_token'] claims = jwt.decode(id_token, public_key, nonce=req_body['nonce'], issuer=issuer, audience=client_id, algorithms=["RS256"]) # nonce Validation if claims['nonce'] != req_body['nonce']: return "invalid id_token" res_body = { "sub": claims["sub"], "email": claims["email"], "email_verified": claims["email_verified"] } return json.loads(json.dumps(res_body)) 起動 docker-compose up -d 参考情報 OpenID Connect python/flaskでgoogleにOpenIDでログインしてみた。ライブラリ無しで。 [Python] PyJWT で Google OAuth 2.0 API の ID Token を検証

Dockerの勉強用にDockerでrailsの環境構築をした 環境構築手順をまとめる Dockerのインストール 下記URLよりDockerをダウンロードしインストールする． https://docs.docker.com/get-docker/ インストールされていることを確認する $ docker version [:|✔ ] Client: Docker Engine - Community Cloud integration: 1.0.9 Version: 20.10.5 API version: 1.41 Go version: go1.13.15 Git commit: 55c4c88 Built: Tue Mar 2 20:13:00 2021 OS/Arch: darwin/amd64 Context: default Experimental: true Server: Docker Engine - Community Engine: Version: 20.10.5 API version: 1.41 (minimum version 1.12) Go version: go1.13.15 Git commit: 363e9a8 Built: Tue Mar 2 20:15:47 2021 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.4.3 GitCommit: 269548fa27e0089a8b8278fc4fc781d7f65a939b runc: Version: 1.0.0-rc92 GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff docker-init: Version: 0.19.0 GitCommit: de40ad0 railsの環境構築 インストールしたDockerを利用して、早速railsの環境を構築する 1. 作業用のディレクトリを作る $ mkdir docker_for_rails27 $ cd docker_for_rails27 2. Dockerfileを作成する $ vi Dockerfile # rails2.7.0を指定 FROM ruby:2.7.0 # パッケージインストール RUN apt-get update -qq && apt-get install -y nodejs postgresql-client RUN mkdir /docker_for_rails27 WORKDIR /docker_for_rails27 COPY Gemfile /docker_for_rails27/Gemfile COPY Gemfile.lock /docker_for_rails27/Gemfile.lock RUN bundle install COPY . /docker_for_rails27 COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3000 # rails起動コマンド CMD ["rails", "server", "-b", "0.0.0.0"] 3. Gemfileを作る vi Gemfile source 'https://rubygems.org' gem 'rails', '~>5.2.4' 空のGemfile.lockを作成する $ touch Gemfile.lock 4. entrypoint.shを作る dockerの初回起動時に実行されるファイル vi entrypoint.sh #!/bin/bash set -e rm -f /docker_for_rails27/tmp/pids/server.pid exec "$@" 5. docker-compose.ymlを作る $ vi docker-compose.yml version: '3' services: db: image: postgres volumes: - ./tmp/db:/var/lib/postgresql/data environment: - POSTGRES_PASSWORD=postgres web: build: . command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" volumes: - .:/docker_for_rails27 ports: - "3000:3000" depends_on: - db 6. 作成したファイルをもとに環境を構築する $ docker-compose run web rails new . --force --no-deps --database=postgresql --skip-bun $ docker-compose build db uses an image, skipping Building web [+] Building 77.7s (15/15) FINISHED => [internal] load build definition from Dockerfile 0.2s => => transferring dockerfile: 559B 0.1s => [internal] load .dockerignore 0.1s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/ruby:2.7.0 0.0s => [ 1/10] FROM docker.io/library/ruby:2.7.0 0.3s => [internal] load build context 5.9s => => transferring context: 41.27MB 5.8s => [ 2/10] RUN apt-get update -qq && apt-get install -y nodejs postgresql-client 16.2s => [ 3/10] RUN mkdir /docker_for_rails27 0.5s => [ 4/10] WORKDIR /docker_for_rails27 0.1s => [ 5/10] COPY Gemfile /docker_for_rails27/Gemfile 0.1s => [ 6/10] COPY Gemfile.lock /docker_for_rails27/Gemfile.lock 0.1s => [ 7/10] RUN bundle install 56.1s => [ 8/10] COPY . /docker_for_rails27 0.6s => [ 9/10] COPY entrypoint.sh /usr/bin/ 0.1s => [10/10] RUN chmod +x /usr/bin/entrypoint.sh 0.7s => exporting to image 2.6s => => exporting layers 2.6s => => writing image sha256:ea82de4e78548b8d350390c1146a3b486a8dbc00b196d6e7c98f03570552c517 0.0s => => naming to docker.io/library/docker_for_rails27_web 0.0s Successfully built ea82de4e78548b8d350390c1146a3b486a8dbc00b196d6e7c98f03570552c517 7. DBの設定を作成する $ vi config/database.yml default: &default adapter: postgresql encoding: unicode host: db username: postgres password: postgres pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> development: <<: *default database: docker_for_rails27_development test: <<: *default database: docker_for_rails27_test production: <<: *default database: docker_for_rails27_production username: docker_for_rails27 password: <%= ENV['DOCKER_FOR_RAILS27_DATABASE_PASSWORD'] %> 8. コンテナを起動する $ docker-compose up 9. DBを作成する docker-compose upした後に別タブで $ docker-compose run web rake db:create 起動したサーバーにアクセスする http://localhost:3000にアクセスする 詰まった部分 config/database.ymlでhostを設定していなかったため、デフォルトのunix domain socketに接続しようとしてdb:createが出来なかった => host: dbを記載することで解決 その際のエラー connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? 参考 https://qiita.com/chisaki0606/items/a4b42af5c4735c94057a https://qiita.com/sagahi/items/ef4b04b5498658bf6210 https://teratail.com/questions/178489

開発PCにmysqlをインストールをしていなかったのですが、dbを使った技術検証をするのに不便だったので、dockerでmysqlコンテナを立てることにしてみました。 ディレクトリ構成は下記になります。 // ディレクトリ構造 ─db └─conf └─mysqld.conf.d my.cnf mysqlの設定として、簡単に以下のファイルを用意しました。 my.cnf [client] default-character-set=utf8mb4 [mysql] default-character-set=utf8mb4 [mysqld] character-set-server=utf8mb4 explicit_defaults_for_timestamp=on 下記のコマンドでdockerコンテナ立ち上げます。 docker run -v ${pwd}/db/conf/mysqld.conf.d:/etc/mysql/conf.d --name mysql -e MYSQL_ROOT_PASSWORD=root -e BIND-ADDRESS=0.0.0.0 -p 3306:3306 -d mysql:5.7 コンテナの状況を確認すると、ちゃんと起動できていることが確認できました。 docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0580fa7597c2 mysql:5.7 "docker-entrypoint.s…" 4 seconds ago Up 3 seconds 0.0.0.0:3306->3306/tcp, 33060/tcp mysql この状況であれば、ホスト側のPCからlocalhostのポート:3306でmysqlに接続することができます。今回はホスト側にmysqlクライアントがインストールされていないので、dockerコンテナを用意してこのコンテナ内から先ほど立ち上げたmysqlコンテナに接続してみます。 > docker run -it --rm mysql:5.7 /bin/bash root@e24782850c58:/# mysql -u root -p -h host.docker.internal Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 7 Server version: 5.7.33 MySQL Community Server (GPL) Copyright (c) 2000, 2021, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> 無事に接続することができました。設定が反映されているかも確認してみます。 mysql> show global variables like 'explicit_defaults_for_timestamp'; +---------------------------------+-------+ | Variable_name | Value | +---------------------------------+-------+ | explicit_defaults_for_timestamp | ON | +---------------------------------+-------+ 1 row in set (0.00 sec) mysql> SHOW VARIABLES LIKE "char%"; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | utf8mb4 | | character_set_filesystem | binary | | character_set_results | latin1 | | character_set_server | utf8mb4 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ 8 rows in set (0.01 sec) mysql> 設定ファイルも無事に反映されていることが確認できました。 ちなみに今回立ち上げたmysqlコンテナはデータを永続化させる設定ではないので、コンテナを削除したらデータが消えてしまうので注意してください。