環境情報 Ubuntu 16.04.3 Docker CE 19.03.12 Docker Compose 1.26.2 PlantUML Server v1.2021.7 前提条件 以下ソフトウェアがインストールされていること Docker CE Docker Compose 作業ログ docker-compose.ymlの作成 以下を少し編集して使用する。 https://github.com/plantuml/plantuml-server/blob/v1.2021.7/docker-compose.yml version: '3.3' services: plantuml-server: image: plantuml/plantuml-server:jetty-v1.2021.7 container_name: plantuml-server ports: - 18080:8080 $ wget https://raw.githubusercontent.com/plantuml/plantuml-server/v1.2021.7/docker-compose.yml ... snip ... 2021-08-06 06:54:54 (29.5 MB/s) - ‘docker-compose.yml’ saved [253/253] $ vim docker-compose.yml $ docker-compose up -d Pulling plantuml-server (plantuml/plantuml-server:jetty-v1.2021.7)... jetty-v1.2021.7: Pulling from plantuml/plantuml-server ... snip ... Creating plantuml-server ... done $ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------- plantuml-server /docker-entrypoint.sh java ... Up 0.0.0.0:18080->8080/tcp ブラウザからhttp://<ホストのIPアドレス>:18080/にアクセス PlantUMLのUIにアクセスできた！

環境 AWS Docker Python django EC2構築 AWSにログイン EC2 ＞ インスタンスを起動をクリックする。 以下を選択する。 OS:Amazon Linux 2 AMI (HVM), SSD Volume Type インスタンスタイプ:t2.micro ネットワーク:デフォルトVPC デフォルトVPCを使うのはベターではないが、とりあえずインターネットに繋がっていれば良いので使用する。 自動割り当てパブリック IP ：有効 ストレージ:8GiB キー:Name,値:Docker-demo セキュリティグループ名：DockerDemo-EC2-SG,説明：DockerDemo-EC2-SG タイプ プロトコル ポート範囲 ソース 説明 SSH TCP 22 カスタム 0.0.0.0/0 - 【設定概要】 VSCodeのRemote-sshでEC2へ接続する...ための事前設定 VSCodeだとフォルダツリーとかグラフィカルで直感的に操作できる。 VSCodeの拡張機能でRemote-SSHをインストール (Macの場合)ターミナルで以下のディレクトリに設定内容を記載する。 ディレクトリ：/Users/(ユーザのホームディレクトリ)/.ssh/config 設定内容： Host Test-EC2 HostName (EC2インスタンスのパブリックIP) IdentityFile (秘密鍵の場所) User ec2-user 以下、設定ログ。 $ cd $ ls -la ~省略~ drwx------ 3 xxxxxx staff 96 1 19 2018 .ssh $ cd .ssh $ touch config $ vi　←ここで設定内容を記載 $ ls -l -rw-r--r-- 1 masudayoshiki staff 117 8 6 18:17 config -rw-r--r-- 1 masudayoshiki staff 2764 5 28 15:59 known_hosts $ cat config Host Test-EC2 HostName (EC2インスタンスのパブリックIP) IdentityFile (秘密鍵の場所) User ec2-user VSCodeのRemote-sshでEC2へ接続する 左下の緑色のSSH:...をクリックする。これは事前設定で作成したconfigのHost 検索窓が出たら、Connect to Host ＞　Test-EC2をクリックする。 これでSSH接続は完了するので、あとはフォルダを開いたり、ターミナルを開いてコマンドを実行する。 いろいろとインストールする前の準備 sudo yum update -y Dockerのインストール&セットアップ sudo amazon-linux-extras install -y docker sudo usermod -a -G docker ec2-user sudo systemctl start docker.service sudo systemctl status docker.service sudo systemctl enable docker.service Docker-composeのインストール&セットアップ sudo curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose アプリに必要なツールのインストール Pythonやそのパッケージをインストールする。 sudo yum install -y python37 python3-devel gcc jq tree git git clone https://github.com/AWSCLOUDTECH/tutorial.git cd tutorial/todobackend cd src pip3 install -r requirements.txt --user python3 manage.py migrate python3 manage.py runserver 0.0.0.0:8000 djangoやPythonのセットアップ アプリのダウンロード＆起動

実は、エラー出たの今日じゃないんです。 約１週間前です。 技術書「Rubyソースコード完全解説」 と 「docker で ruby」構築 https://qiita.com/kaizen_nagoya/items/a00fec16fb43e6e9071d bash checking for ruby... false configure: error: cannot run /bin/bash tool/config.sub configure: error: cannot run /bin/bash tool/config.sub on ubuntu:trusty #22 https://github.com/rubyomr-preview/rubyomr-preview/issues/22 wuzzzzaah/rubyインストール https://gist.github.com/wuzzzzaah/0a7835a1182c3c23124a bash # apt update; apt -y upgrade; # apt -y install build-essential git curl zlib1g-dev libssl-dev libreadline-dev libyaml-dev libxml2-dev libxslt-dev sqlite3 libsqlite3-dev nodejs # git clone git://github.com/sstephenson/rbenv.git .rbenv # echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc # echo 'eval "$(rbenv init -)"' >> ~/.bashrc # exec $SHELL bash: rbenv: command not found # mkdir -p ~/.rbenv/plugins 今日のDocker error:docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. https://qiita.com/kaizen_nagoya/items/bea99f4c1c0cb746029d

数日ぶりにdockerを起動しようとした。 そういえば、今朝からMacintoshのファンがうんうんうなってた。 てあたりしだいkill -9 xxxx をした気がする。 bash $ docker run -it kaizenjapan/ruby /bin/bash docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. See 'docker run --help'. こういう場合、macOSならGUIからアプリを起動するのがいいのだろうか。 docker run -it kaizenjapan/ruby /bin/bash Unable to find image 'kaizenjapan/ruby:latest' locally latest: Pulling from kaizenjapan/ruby 7a72d62e9d2f: Downloading 39.18MB/54.9MB 0f297180bbe0: Download complete 13e579aa043f: Download complete ffdc07b7fd30: Downloading 39.23MB/54.57MB 2450ed8a1856: Downloading 72.55MB/196.4MB 41030cb92044: Waiting c11b933c29c4: Waiting ceded6dd6885: Waiting 8bd94d6d8d5f: Waiting なんとか起動しそう。 ときどき、loginしろっていうエラーが出ることがある。 今日はなぜでなかったかわからない。

Dockerとは コンテナ仮想化を用いてアプリを開発・配置・実行するためのソフトウェア。 インフラのコード化(IaC)にも役立つ。 従来の仮想化との違い 一般的な仮想サーバというと、CPUやメモリなどのハードウェアリソースを分割し、複数の独立したサーバのように機能させるもの。 コンテナも、隔離されたユーザー環境(ユーザーがアプリを実行するためのリソースがセットで提供される空間)を提供する点は同じだが、1つのOSのカーネルを共有している点が仮想マシンとは大きく異なる。 しかし、DockerエンジンにもOS(Linux系)が含まれている。ややこしいが、まるまるOSが入っているわけでなく、カーネルだけをホストOSと共有している。 Dockerと検索して出てくる説明や図では、「ゲストOSがないから早い！」的な短絡的な内容が書かれているが、実際には 仮想マシンはカーネルまで仮想化しているが、コンテナはカーネルをホストOSと共有しているから、軽量・高速を実現している ということらしい。 画像引用：さくらのナレッジ:Dockerとは何か、何が良いのか 世間の注目度 AWS,GCP,AZUREなどのパブリッククラウドやプライベートクラウドが普及し始めて、アプリの実行環境の種類が増えた。それに伴い、どのような環境でも動かせるコンテナの注目度は高い。 実際、世界の開発者のトレンドの調査として「Stack Overflow Developer Survey 2020」では、開発者が関心を示しているプラットフォームの割合として、Linuxに次いて2番目となっている。 用語 Docker Daemon Dockerエンジンの一部で、Dockerの主要機能。 コマンドの受付場所。命令をREST APIで受け付ける。 他のDockerの機能に命令を出す。 Docker Client コマンドの発行場所。Docker Daemonとやりとりする。 Docker image このファイルをもとにコンテナを起動する。 アプリやOSがひとまとめになったもの。 Docker レジストリ Docker imageのファイル置き場。 例：Dockerhub(パブリック) 　　AWS ECR　(プライベート) Docker file Docker imageをカスタマイズする指示内容を記述したテキストファイル。これによりOS設定やインフラ構築部分をコード化出来る。

M1 Mac関連の問題 Dockerコンテナでyarnをインストールする Docker に yarn を入れるための yarnpkg で no valud opengpg data found になった時の対処法 M1 MacでHeroku containerにデプロイしたら Exec format error と出て困った話 M1 MacでHerokuにデプロイする手順 docker-compose build Dockerでコンテナ内にbundle installされない問題の解決法

BuildKitとは Docker Buildの拡張版 最新版(20.10.7)ではデフォルトで有効になっている (デフォルトでDOCKER_BUILDKIT=1の状態になっている) BuildKitができること ビルドの並列実行 ビルドキャッシュのインポート/エクスポート マルチプラットフォーム対応 etc 2つのBuildKit環境 BuildKitは2つの実行環境がある Docker Engineに内蔵されたBuildKit (デフォルト) buildkitデーモンとして独立した環境のBuildKit デフォルトのDocker Engineに内蔵されたBuildKitは一部機能のみしか使えない buildkitデーモン版のBuildKitはすべての機能を利用できるがbuildctlというコマンドを使う必要がある docker-buildxプラグインを使用すると、docker buildxコマンドからbuildkitデーモンを操作できる # 最新版(20.10.7)ではデフォルトで有効 ビルダーインスタンス BuildKitはbuilderインスタンスというものを起動して、そのインスタンス内部でビルドする仕組みなっている builderインスタンスはdocker buildx lsで確認することができる デフォルトではdockerドライバ(Docker内蔵版BuildKitを使う)のビルダーインスタンスが有効になっている docker-containerドライバ(buildkitデーモン版BuildKitを使う)のビルダーインスタンスを使うには最初に自分で作成する必要がある docker-containerドライバのビルダーインスタンスを作成する ビルダーインスタンスの作成 % docker buildx create --name docker-container-builder --use % docker buildx ls NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS docker-container-builder * docker-container docker-container-builder0 unix:///var/run/docker.sock inactive desktop-linux docker desktop-linux desktop-linux running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6 default docker default default running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6 ビルダーインスタンスの起動 (オプション) ビルド時に自動で起動されるので明示的に起動しなくても大丈夫 % docker buildx inspect --bootstrap [+] Building 10.9s (1/1) FINISHED => [internal] booting buildkit 10.9s => => pulling image moby/buildkit:buildx-stable-1 9.7s => => creating container buildx_buildkit_docker-container-builder0 1.1s Name: docker-container-builder Driver: docker-container Nodes: Name: docker-container-builder0 Endpoint: unix:///var/run/docker.sock Status: running Platforms: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6 % docker buildx ls NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS docker-container-builder * docker-container docker-container-builder0 unix:///var/run/docker.sock running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6 desktop-linux docker desktop-linux desktop-linux running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6 default docker default default running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6 マルチプラットフォーム対応のDockerイメージの作成 デフォルトではビルド環境と同じプラットフォームのDockerイメージしか作成できないが、 docker-containerドライバのビルダーインスタンスを使うとマルチプラットフォーム環境のDockerイメージを作成することができる。 サンプルのDockerfile FROM alpine:latest CMD ["arch"] デフォルトのビルド (シングルプラットフォーム対応) % docker buildx use default % docker buildx build -t boccifarm/sample-single-platform-image --load . % docker image inspect boccifarm/sample-single-platform-image | jq -r '.[].Architecture' amd64 マルチプラットフォーム対応ビルド 現状ではローカルに自アーキテクチャと異なったイメージをロードできないのでDockerHubへプッシュする % docker login % docker buildx use docker-container-builder % docker buildx build -t boccifarm/sample-multi-platform-image --platform linux/amd64,linux/arm64 --push . % docker manifest inspect --verbose boccifarm/sample-multi-platform-image | jq -r '.[].Descriptor.platform' { "architecture": "amd64", "os": "linux" } { "architecture": "arm64", "os": "linux" } マルチプラットフォーム対応の確認 amd64環境とarm64環境のKubernetes上でマルチプラットファーム対応していることを確認する # amd64のKubernetes % kubectl run test --restart=Never --image=boccifarm/sample-multi-platform-image % kubectl logs -f test x86_64 # arm64のKubernetes % kubectl run test --restart=Never --image=boccifarm/sample-multi-platform-image % kubectl logs -f test aarch64 参考 https://qiita.com/tatsurou313/items/ad86da1bb9e8e570b6fa https://roy-n-roy.github.io/Docker/BuildKit/ https://dev.classmethod.jp/articles/docker-multi-architecture-image-build/

はじめに EC2内にインストールしてあるDockerを、AWS EFSとマウントすることをやってみました。 手順を公開したいと思います。 ・EC2のOS：Ubuntu 20.04.2 LTS ・Dockerバージョン：Docker version 20.10.8, build 3967b7d 構成図 簡単に説明すると、 １.EC2内にDockerをインストールしておリます。 ２.EFSがEC2とマウントしておリます。 ３.DockerがEFSとのマウントを実現できております。 １.EC2内にDockerをインストール UbuntuにDockerをインストールにあたって、下記の記事が大変参考になりました。 記事に従ってインストール作業をしたら、Dokcerのインストールが無事に完了しました。 $ docker --version Docker version 20.10.8, build 3967b7d ２.EC2とEFSをマウント EFSの作成手順はここで割愛させていただきます。 EC2とEFSのマウント方法は、下記の記事が大変参考になりました。 記事に従って操作すると、EC2内に/mnt/efsディレクトリーを作成しておき、それをEFSとのマウントを実現できておリます。 $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 20G 2.2G 18G 12% / devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 388M 900K 387M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/loop1 26M 26M 0 100% /snap/amazon-ssm-agent/4544 /dev/loop0 34M 34M 0 100% /snap/amazon-ssm-agent/3552 /dev/loop3 71M 71M 0 100% /snap/lxd/19647 /dev/loop4 33M 33M 0 100% /snap/snapd/11588 /dev/loop2 56M 56M 0 100% /snap/core18/1997 fs-XXXXXXXXX.efs.ap-northeast-1.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs overlay 20G 2.2G 18G 12% /var/lib/docker/overlay2/193018e5f21d57c9462cc7f9d6ed33f83a59506c599d3d4739d3d81712c52469/merged tmpfs 388M 0 388M 0% /run/user/0 また、/etc/fstabにEFSの情報を登録することによって、EC2が起動されるタイミングで、自動的にEFSとマウントを実現することができます。 $ cat /etc/fstab LABEL=cloudimg-rootfs / ext4 defaults,discard 0 1 fs-XXXXXXXXX:/ /mnt/efs efs defaults,_netdev 0 0 EFS内に確認用のlalala.txtファイルを作成し、中に適当に文字を入れておきます。 $ pwd /mnt/efs $ sudo touch lalala.txt $ sudo chmod 775 lalala.txt $ sudo vi lalala.txt $ cat lalala.txt 123123lalala ３.DockerとEFS間のマウントを実現 今回はnginxのDockerを使用し、EFSとのマウントを試してみました。 まずはnginxのDokcerをインストール前に、Dockerがないことを確認します。 $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES EC2上の/mnt/efsはすでにEFSとマウントしてありますので、 これからはnginxのdocker内に/mnt/efsをEC2上の/mnt/efsをマウントし、 DockerとEFSのマウントを実現します。 $ sudo docker run --privileged=true -it --name nginx -d -p 8080:80 -v /mnt/efs:/mnt/efs nginx /bin/bash 369b6256d0ff62337abb2ca2067a90de2053253da379502fdccc3a95cbe92937 続いてngixnのDocker状態を確認し、起動できていることを確認しております。 $ sudo docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 369b6256d0ff nginx "/docker-entrypoint.…" 31 seconds ago Up 31 seconds 0.0.0.0:8080->80/tcp, :::8080->80/tcp nginx nginxのDocker内部へ接続していきます。 $ sudo docker exec -it 369b6256d0ff bash root@369b6256d0ff:/# nginxのDocker内部の/mnt/efsに移動します。 root@369b6256d0ff:/# ls -all total 80 drwxr-xr-x 1 root root 4096 Aug 6 03:33 . drwxr-xr-x 1 root root 4096 Aug 6 03:33 .. -rwxr-xr-x 1 root root 0 Aug 6 03:33 .dockerenv drwxr-xr-x 2 root root 4096 Jul 21 00:00 bin drwxr-xr-x 2 root root 4096 Jun 13 10:30 boot drwxr-xr-x 10 root root 3020 Aug 6 03:33 dev drwxr-xr-x 1 root root 4096 Jul 22 10:13 docker-entrypoint.d -rwxrwxr-x 1 root root 1202 Jul 22 10:12 docker-entrypoint.sh drwxr-xr-x 1 root root 4096 Aug 6 03:33 etc drwxr-xr-x 2 root root 4096 Jun 13 10:30 home drwxr-xr-x 1 root root 4096 Jul 22 10:13 lib drwxr-xr-x 2 root root 4096 Jul 21 00:00 lib64 drwxr-xr-x 2 root root 4096 Jul 21 00:00 media drwxr-xr-x 1 root root 4096 Aug 6 03:33 mnt drwxr-xr-x 2 root root 4096 Jul 21 00:00 opt dr-xr-xr-x 177 root root 0 Aug 6 03:33 proc drwx------ 2 root root 4096 Jul 21 00:00 root drwxr-xr-x 3 root root 4096 Jul 21 00:00 run drwxr-xr-x 2 root root 4096 Jul 21 00:00 sbin drwxr-xr-x 2 root root 4096 Jul 21 00:00 srv dr-xr-xr-x 13 root root 0 Aug 6 03:33 sys drwxrwxrwt 1 root root 4096 Jul 22 10:13 tmp drwxr-xr-x 1 root root 4096 Jul 21 00:00 usr drwxr-xr-x 1 root root 4096 Jul 21 00:00 var root@369b6256d0ff:/# cd /mnt/efs root@369b6256d0ff:/mnt/efs# pwd /mnt/efs EFS上のファイルがDocker内にあることを確認できておリます。 root@369b6256d0ff:/mnt/efs# ls lalala.txt root@369b6256d0ff:/mnt/efs# cat lalala.txt 123123lalala さらに、nginxのDocker内に、ファイルを作成してみました。 root@369b6256d0ff:/mnt/efs# touch dadada.txt root@369b6256d0ff:/mnt/efs# ls dadada.txt lalala.txt nginxのDockerをログアウトし、EC2画面に戻り、EC2でEFS上の内容を確認しておくと、同じように、先ほど作成したファイルがあることを確認できておリます。 root@369b6256d0ff:/mnt/efs# exit exit $ pwd /mnt/efs $ ls dadada.txt lalala.txt これでEC2内のDockerをEFSとマウントは実現できました。

DockerでWordPress環境を構築 前提としてDockerとNode.jsがインストールされていること。 目的 WordPressでチーム開発する予定が立ちそうなのでメモを兼ねて書くことにしました。 できること dockerを用いてWordPressの環境を作る。 今回はwp-envを使用して立ち上げる。 順番にやっていくだけで構築できるはずです。 開発環境 Windows10pro Docker version 20.10.7 npm version 7.19.0 node version 14.17.0 pacage.jsonを作成 任意のディレクトリに移動したら npm init pacagenameなどが問われますが特になければエンター連打でOK ディレクトリ内にファイルができていることを確認 wp-envのインストール npm i @wordpress/env --save-dev このコマンドでインストールできる。 node_modulesが作成される。 同時にpacage-lock.json（インストール情報が載ったファイル）というファイルも作成される。 pacage.jsonにコマンドを追記する ・pacage.json元 { "name": "wptest", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { // 6行目前後のここに書く "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC", "devDependencies": { "@wordpress/env": "^4.1.0" } } "wp-env": "wp-env",をscriptsに追記する。 { "name": "wptest", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "wp-env": "wp-env", ←ここに追記 "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC", "devDependencies": { "@wordpress/env": "^4.1.0" } } これでnpm run wp-envが使用できるようになる WordPressをダウンロードして立ち上げる。 npm run wp-env start これでDockerが立ち上がってWordPressがダウンロードされて環境が構築される docker desktopを見てmysqlやWordPressのコンテナが起動していることを確認 これでもう起動しているでブラウザで localhost:8888 で検索するとトップページが開く localhost:8888/wp-login.php 検索すると管理ページのログイン画面に飛べます アドレスが admin パスワードが password でログインできます。（初期設定の簡単で危険なアドレスとパスワードなので必要に応じて再設定してください。） 以上で環境構築までは完了です。 日本語設定 サイドバーのsettinggのgeneralからsite languageを日本語に切り替え タイムゾーンを＋９ に設定して保存 wp-envを用いてプラグインやテーマをインストール .wp-env.jsonというファイルをルート直下に作成 プラグインをインストールしてみよう 今回は日本語版に必須なMV Multibyte Patchをインストールします。 ブラウザでMV Multibyte Patchで検索しこのページを開きます(大体検索結果の上の方にあります。) もしくはこちらhttps://ja.wordpress.org/plugins/wp-multibyte-patch/ 開けたらダウンロードボタンのリンクのアドレスをコピーする .wp-env.jsonを開き以下のように記述 { "plugins": [ "ここにインストールしたいプラグインのURLを追記", "2個目のプラグイン", "3個目のプラグイン" ] } 今回の場合はこのような記述になります。 { "plugins": [ "https://downloads.wordpress.org/plugin/wp-multibyte-patch.2.9.zip" ] } ここまで完了したら以下のコマンドを実行 npm run wp-env start --update 再起動がかかりアップデートされる。 再度ワードプレス管理画面のプラグインを見るとMV Multibyte Patchがインストールされていて有効化もしていることが確認できます。 テーマを作ろう ルート直下に好きなテーマ名のフォルダを作成 今回はsample そのフォルダに最低限のindex.phpとstyle.cssファイルを作成 .wp-env.jsonを開き以下のように記述 { "plugins": [ "https://downloads.wordpress.org/plugin/wp-multibyte-patch.2.9.zip" ], // ここから追記 "themes": [ "./sample" ←sampleには先ほど作成したフォルダ名を記述 ] 　 // ここまで } ここまで完了したら以下のコマンドを実行 npm run wp-env start --update 再起動がかかりアップデートされる。 管理ページのテーマを見ると追加されていることが分かる。 チーム開発にも使える。 gitなどでこのファイル群を共有して npm install で各環境にwp-envの環境を入れます。 そして npm run wp-env start とすると同じ環境で開発することができる。

DockerでWordPress環境を構築 前提としてDockerとNode.jsがインストールされていること。 目的 WordPressでチーム開発する予定が立ちそうなのでメモを兼ねて書くことにしました。 できること dockerを用いてWordPressの環境を作る。 今回はwp-envを使用して立ち上げる。 順番にやっていくだけで簡単に構築できるはずです。 環境構築が苦手な僕でも10分くらいで完了しました。笑 開発環境 Windows10pro Docker version 20.10.7 npm version 7.19.0 node version 14.17.0 pacage.jsonを作成 任意のディレクトリに移動したら npm init pacagenameなどが問われますが特になければエンター連打でOK ディレクトリ内にファイルができていることを確認 wp-envのインストール npm i @wordpress/env --save-dev このコマンドでインストールできる。 node_modulesが作成される。 同時にpacage-lock.json（インストール情報が載ったファイル）というファイルも作成される。 pacage.jsonにコマンドを追記する ・pacage.json元 { "name": "wptest", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { // 6行目前後のここに書く "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC", "devDependencies": { "@wordpress/env": "^4.1.0" } } "wp-env": "wp-env",をscriptsに追記する。 { "name": "wptest", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "wp-env": "wp-env", ←ここに追記 "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC", "devDependencies": { "@wordpress/env": "^4.1.0" } } これでnpm run wp-envが使用できるようになる WordPressをダウンロードして立ち上げる。 npm run wp-env start これでDockerが立ち上がってWordPressがダウンロードされて環境が構築される docker desktopを見てmysqlやWordPressのコンテナが起動していることを確認 これでもう起動しているでブラウザで localhost:8888 で検索するとトップページが開く localhost:8888/wp-login.php 検索すると管理ページのログイン画面に飛べます アドレスが admin パスワードが password でログインできます。（初期設定の簡単で危険なアドレスとパスワードなので必要に応じて再設定してください。） 以上で環境構築までは完了です。 日本語設定 サイドバーのsettinggのgeneralからsite languageを日本語に切り替え タイムゾーンを＋９ に設定して保存 wp-envを用いてプラグインやテーマをインストール .wp-env.jsonというファイルをルート直下に作成 プラグインをインストールしてみよう 今回は日本語版に必須なMV Multibyte Patchをインストールします。 ブラウザでMV Multibyte Patchで検索しこのページを開きます(大体検索結果の上の方にあります。) もしくはこちらhttps://ja.wordpress.org/plugins/wp-multibyte-patch/ 開けたらダウンロードボタンのリンクのアドレスをコピーする .wp-env.jsonを開き以下のように記述 { "plugins": [ "ここにインストールしたいプラグインのURLを追記", "2個目のプラグイン", "3個目のプラグイン" ] } 今回の場合はこのような記述になります。 { "plugins": [ "https://downloads.wordpress.org/plugin/wp-multibyte-patch.2.9.zip" ] } ここまで完了したら以下のコマンドを実行 npm run wp-env start --update 再起動がかかりアップデートされる。 再度ワードプレス管理画面のプラグインを見るとMV Multibyte Patchがインストールされていて有効化もしていることが確認できます。 テーマを作ろう ルート直下に好きなテーマ名のフォルダを作成 今回はsample そのフォルダに最低限のindex.phpとstyle.cssファイルを作成 .wp-env.jsonを開き以下のように記述 { "plugins": [ "https://downloads.wordpress.org/plugin/wp-multibyte-patch.2.9.zip" ], // ここから追記 "themes": [ "./sample" ←sampleには先ほど作成したフォルダ名を記述 ] 　 // ここまで } ここまで完了したら以下のコマンドを実行 npm run wp-env start --update 再起動がかかりアップデートされる。 管理ページのテーマを見ると追加されていることが分かる。 チーム開発にも使える。 gitなどでこのファイル群を共有して npm install で各環境にwp-envの環境を入れます。 そして npm run wp-env start とすると同じ環境で開発することができる。

こんにちは。まゆみです。 Dockerについての記事をシリーズで書いています。 今回の記事では、CI/CDパイプラインの流れの TravisCIテスト ➡ ElasticBeanStalkでdeploy の部分にフォーカスを置き TravisCIでテストを自動的に実行させるにはどうしたら良いのか？ テストがパスした後に、ElasticBeanStalkでdeployするにはどうしたら良いのか ということを書いていこうと思います Github Repositoryにソースコードをアップする こちらの記事は、Githubにソースコードをアップさせた後からのワークフローを書いています。 もし、Github　Repositoryにソースコードをアップさせる方法が分からない方はこちらとこちらの記事に書いています。 ①git init ②git add . ③git commit -m"コミットした時のメッセージ" ④git remote add origin ＜github repositoryのアドレス＞ ⑤git push origin master がGithub Repositoryにpushするおおよその流れになります。 その後、Github Repositoryにちゃんとpushされたことを確認します TravisCIとGithub Repositoryを連動させる Travis CIは、Github Repositoryに新しいコードがpushされた時、またはコードが更新された時、Githubからそのソースコードを引っ張ってくることができます。 TravisCIのページからOauthを利用してGithubアカウントと紐づけしましょう 注意 TravisCIは『.org』ではなく、『.com』の方を使ってください。 .travis.yamlファイルを記入する TravisCIとGithubが連携させたあと、あなたがTravisCIに自動化してやってもらいことをyamlファイルに書く必要があります 『.travis.yaml』ファイルをプロジェクトフォルダー内に作ってください。(ファイル名travisの前に . (ドット)があることに注意です。) TravisCIに自動化してやってもらいこと Dockerのコピー Dockerfile.devファイルを使ってイメージを作る テストスイートを実行する事 AWSにコードをdeployする事 以上のことをyamlファイルに書いていきます。 そしてここでなぜ、Dockerfileではなく、Dockerfile.devを使ってイメージを作成するのか？という疑問がわいてきた方もいると思います DockerfileはProductionのためのファイルであり、テストスイートを実行させるコードを含んでいないからです。 .travis.yamlファイルの書き方(前半) とりあえず、AWSにコードをdeployする指示を書く前の段階までを書いて解説していきます Dockerのコピー Dockerfile.devファイルを使ってイメージを作る テストスイートを実行する事　　<----ここまで AWSにコードをdeployする事 .travis.yamlファイルの前半部分の完成形は下のスクショのようになります 後半部分については、AWSのElasticBeanStalkでdeployする方法を後述するときに説明します。 上のスクショに振っている番号と照らし合わせながら、1行づつ説明していきます ①sudo: required コードの実行にスーパーユーザー権限が必要なので書きます。 ②services AWSでdeployしたいサービス名を書きます。 今回はDocker CLIが必要なので、 - docker と書きます。 ③before_install テストスイートが実行される前に実行されるべきコマンドを書きます 今回の記事では、Reactのアプリを作る時の一連の流れを例として扱っています。 (Reactを使ったアプリを作る時のテストスイートを実行するコマンドについてはこちらで説明しています) -tオプションをつけて、次の段階(テストスイートを実行する段階)でImageIDを探さなくて良いようにしておきます ④script テストスイートを実行するためのコマンドを書きます ただテストスイートの実行をディフォルトのまま使うと、テスト実行後もそこから抜け出ずに、コンピューターがあなたからの指示待ち状態になります。(下のスクショ参考) テストが1回終わったら抜け出るようにするには -- --coverage オプションを付けて実行します -- --coverageでも抜け出れない。 私の場合もそうなんですが、『-- --coverage』オプションを付けても抜け出れない場合があります。 その時の答えはStackOverFlowにありました。 -- --coverageで上手く抜け出ることができない方は、下のコマンドを試してみてください。 docker run -e CI=true <ImageID> npm run test Githubにpush する .travis.ymlの前半が書き終わったので、これをGithubにpushします git add . git commit -m "メッセージ" git push origin master そのあと、TravisCIに戻ると、TravisCIがGithubからソースコードを引っ張ってテストスイートを実行してくれているのが分かります exited with 0 と表示されたら、テストが上手くいったことを示しています AWS　ElasticBeanStalk では次にAWSのページを開き、サービス名elasticbeanstalk を検索窓に入力して、アプリケーションを作ります。 環境を作ります 今回はWebアプリなのでウェブサーバー環境を選択してください。 アプリケーション名をあなたが好きなようにつけてください。(のちにyamlファイルに書くので覚えておいてくださいね。) また、プラットフォームにDocker を選択してください。 注意： あなたの使っている環境によっては、プラットフォームにDocker を選択した時に自動的に選択されるプラットフォームのブランチが『64 bit Amazon Linux 2』ではうまく行かない時もあります。 その場合は『64 bit Amazon Linux』を選択してください。 その後、作成ボタンをクリックすると、AWSがElasticBeanStalkを作ってくれます。 少し時間がかかります 3～5分くらい待たないといけませんが、気長に待ちましょう 下の様になればOKです。 赤の矢印の部分をクリックすると ディフォルトのアプリケーションになります .travis.yamlファイルの書き方(後半) では、yamlファイルの後半部分を書いていきます deploy　> provider どのサービスを使ってdeployするのかを書きます。 deploy > region regionに何を書くべきかは、上のスクショの赤の矢印の部分に書かれています deploy > app 最初にElastic Bean Stalk を立ち上げた時につけたアプリケーション名を書きます deploy > env 上のスクショの赤の矢印に書かれたテキストを書きます deploy > bucket_name Github Repositoryから渡されてきたコードはS3 bucketに渡されます。 そのため、バケット名を書く必要があります AWSのサービス『S3』で検索して、S3のページを開きましょう。 すると、バケットが作られているので、この名前をコピーしてyamlファイルに記載します deploy > bucket_path 先ほど『deploy > app』に書いたものをそのまま書きます。 deploy > on branch: master と書くことで、master以外のbranch(例えばfeatureブランチなど)にコードがアップされた時は、deployされないが、masterブランチにコードがpushされた時はdeployされるということになります yamlファイルは前半の部分も含めて下のようになります AWSのIAMユーザーに追加する TravisCIによって使われるべきIAMユーザーを追加します IAMのユーザー追加から ElasticBeanStalkのすべての権限を与えます ユーザーが追加されました。 ユーザー追加の最後のページにシークレットアクセスキーとパスワードが記載されていますが、これらについてはyamlファイルにそのまま書くことができませんよね。 なぜならGithub Repositoryにアップするので。 そこで、TravisCIでこのシークレットアクセスキーなどの環境変数を設定して、yamlファイルには環境変数によって管理します TravisCIのEnvironment Variable 下のスクショにあるように、赤で囲まれた『settings』をクリックしてください。 そして、『Environment Variable』のセクションを探します AWSのアクセスキーとシークレットキーをそれぞれ環境変数に代入してください。 その時に『DISPLAY VALUE IN BUILD LOG』と書かれたスイッチみたいになっているところがオフになっていることを確かめてください。 yamlファイル yamlファイルの最後に access_key_id: secret_access_key: を書きます。 そして、先ほどTravisCIで設定した環境変数をこちらに書きます ポートをあけるための指示 Webアプリなのでポートを開けます。 その指示は、コマンドラインでするのではなく、Dockerfileに書きます。 EXPOSE <ポート番号> とDockerfileに書きましょう 最後に、ソースコードに変更が加わった時は git add . git commit -m "メッセージ" git push origin master でGithubにpushしてくださいね。 AWSのElasticBeanStalkに書いてあるURLをクリックするとあなたのWebアプリのページにアクセスする事ができます　＼(^o^)／

今回の問題 今回はただ今Docker初心者の私がとても悩んだ問題です。 正直、メンターさんと一緒に考えてもなかなか答えが見えなかった問題でした。 調べても調べてもなかなか出てこなくてものすごく大変でした。 やっと解決したので、今後のためにも残しておこうと思います。 使用環境 ・Ruby(2.5.7) ・Ruby on Rails (6.1.3.2) ・Docker (20.10.7) ・MySQL (5.7) 問題点 上のスクリーンショットを見ていただくと、本来スクリーンショット最下部「Use Ctrl-C to stop」以下にRailsのログ情報が本来出力されるはずなのですが、Railsを起動して画面読み込みをしても何もログが出力されていません。（動作自体は正常にしています。） ターミナル $ docker-compose up -d $ docker attach onsen_app_1 で起動したコンテナに接続してもRailsのログは出力されませんでした。 Docker化する以前は問題なくRailsログがターミナルに出力されていたので、Docker化した際の設定に原因があるかと思いましたが、調査してもどこが引っかかっているのかわかりませんでした。 解決方法 結論を先に言うと、今回の原因は「config/environments/development.rb」にある記述を追加すれば正常に動くことができました。 development.rb Rails.application.configure do # ... config.logger = Logger.new(STDOUT) # ... end 上記に書いた「config.logger = Logger.new(STDOUT)」と言うのを「config/environments/development.rb」に追加すれば、正常に動くようになりました。 ちなみに「rails STDOUT not working docker」で検索したらようやくヒットしました。 最後に Dockerはまだまだ初心者ゆえに大変な作業でした。 これからもDockerにはお世話になると思うので、勉強は怠らずに励んでいきたいですね。 変なまとまりになりましたが、以上で終了です。 見て頂きありがとうございました。 参考サイトです。 https://blog.eq8.eu/til/ruby-logs-and-puts-not-shown-in-docker-container-logs.html

仕事でインフラ担当者が用意したJenkinsやDockerを使っていますが、使っているだけであまり詳しくないので勉強しました。 事前にwarファイル作成対象のプロジェクトを、GitHubにpushしておきます。 https://github.com/jirentaicho/jenkinstest devenvにDockerの設定ファイル等があります。 やること Dockerで以下のコンテナを作成します。 Jenkins Tomcat JenkinsはGitHub上のソースを取得して、GitHub上のJenkinsfileに従ってタスクを実行します。 行うタスクは以下の通りです。 コンパイル テスト warファイルの出力 Tomcatコンテナにデプロイ デプロイには、Deploy to containerというJenkinsのプラグインを利用します。 dockerコンテナの準備 Jenkins用のコンテナと、Tomcat用のコンテナを用意します。 構成 フォルダ構成は以下のようにしました。 devenv │ docker-compose.yml │ ├─jenkins │ └─data └─tomcat Dockerfile Dockerfileは以下のようになっています。 Dockerfile FROM tomcat:9.0 RUN apt-get update && apt-get install -y wget && apt-get install -y vim docker-compose.ymlは以下のようになっています。 docker-compose.yml version: '3' services: tomcat: build: context: . dockerfile: ./tomcat/Dockerfile container_name: tomcat privileged: true ports: - "8012:8080" volumes: - "./tomcat/data:/var" tty: true jenkins: container_name: jenkins image: jenkins/jenkins ports: - "8888:8080" volumes: - "./jenkins/data:/var/jenkins_home" tty: true links: - tomcat devenvフォルダで、以下のコマンドを打ってコンテナ立ち上げまで行います。 docker-compose up -d Tomcatの設定 TomcatのWebアプリケーションマネージャの設定を行うことで、Jenkinsでのデプロイ作業が凄く簡単になりますので、Tomcatの設定を行います。 ロールとユーザーの追加 まずはtomcatコンテナに入ってtomcat-users.xmlを修正します。 docker exec -it tomcat bash root@be401ef0872b:/usr/local/tomcat# find / -name tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml root@be401ef0872b:/usr/local/tomcat# vim /usr/local/tomcat/conf/tomcat-users.xml ファイルの最後のほうに以下のようなロールとユーザーを追加しました。 ※jenkinsから実行するのでmanager-scriptを追加しています。 tomcat-users.xml <role rolename="manager-gui"/> <role rolename="admin-gui"/> <role rolename="manager-script"/> <user username="misaka" password="password" roles="manager-gui,admin-gui,manager-script"/> </tomcat-users> managerフォルダのコピー 次にwebapps.distフォルダのmanagerをwebappsフォルダにコピーします。 というのも、初期状態ではwebappsフォルダが空っぽです。 root@be401ef0872b:/usr/local/tomcat# cp -r webapps.dist/manager webapps root@be401ef0872b:/usr/local/tomcat# root@be401ef0872b:/usr/local/tomcat# ls BUILDING.txt LICENSE README.md RUNNING.txt conf logs temp webapps.dist CONTRIBUTING.md NOTICE RELEASE-NOTES bin lib native-jni-lib webapps work root@be401ef0872b:/usr/local/tomcat# cd webapps root@be401ef0872b:/usr/local/tomcat/webapps# ls manager context.xmlの修正 許可するIPアドレスに関して修正します。今回はコメントアウトしてなんでも許可するようにしました。 # find ./ -name context.xml ./conf/context.xml ./webapps/manager/META-INF/context.xml vim webapps/manager/META-INF/context.xml 許可しているIPアドレスのところは<!-- -->でコメントアウトできます。 context.xml <!-- <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> --> 画面確認 実際に画面を確認します。 ※Tomcatが起動していない場合は以下のコマンドで起動します。 root@be401ef0872b:/usr/local/tomcat# /usr/local/tomcat/bin/startup.sh このhttp://localhost:8012/manager/html にアクセスして、先ほど設定したIDとパスワードでログインすると以下の画面が表示されます。 → 今回はmisaka/passwordです。 Jenkinsの設定 次にJenkinsの設定を行います。 Jenkinsでやることは、プラグインのインストールとジョブの作成になります。 Deploy to container プラグインのインストール Jenkinsの初期設定を済ませたら、「Deploy to container」プラグインのインストールを行います。 パイプラインジョブの作成 ジョブを作成します。 パイプラインのジョブを作成したら、以下の画像のように設定します。 リポジトリURLには自身のGitHubのプロジェクトを指定してください。 また、GitHubでリポジトリを作った時の初回コミットのブランチをmainにすることが多いかもしれないので、Jenkinsのブランチ指定子には存在するブランチ名を入力してください。 Pipeline Syntaxの設定 ジョブを選択した時の画面の左メニューにPipeline Syntaxをクリックします。 Sample Stepに「deploy: Deploy war/ear to a container」を選択して WAR/EAR filesは「*/.war」と入力します。 認証情報の追加をしたらGenerate Pipeline Scriptを押してスクリプトの生成をします。 ※追加ボタンを押して以下のような認証情報を追加します(Tomcatで設定したユーザー名とパスワード) Generate Pipeline Scriptを押下して出力されたスクリプトをJenkinsfileで利用します。 Javaのプロジェクトと一緒にJenkinsfileをGithubに上げていますが、以下のような内容になっています。 やっていることは単純です。先ほどGenerateしたスクリプトはデプロイステージで利用しています。 jenkinsfile pipeline { agent any options { skipStagesAfterUnstable() } stages { stage('Build') { steps { echo 'Build..' checkout([$class: 'GitSCM', branches: [[name: '*/main']], userRemoteConfigs: [[url: 'https://github.com/jirentaicho/jenkinstest.git']]]) sh './mvnw clean compile' } } stage('Test'){ steps { echo 'Test..' sh './mvnw test' } } stage('Make war file'){ steps { echo 'Make war' sh './mvnw package' } } stage('Deploy') { steps { echo 'Deploy..' deploy adapters: [tomcat9(credentialsId: 'tomcat_misaka', path: '', url: 'http://192.168.11.13:8012')], contextPath: null, war: '**/*.war' } } } } ジョブ実行 ジョブ実行してコンソールを確認して「Finished: SUCCESS」となっていればデプロイまでOKです。 デプロイが完了したら、結果を見てみます。 今回はmyprojectというwarをデプロイしたので、myprojectというフォルダができています。 そしてJavaではapi/helloにアクセスしたときにメッセージを返すという素晴らしいプロジェクトを作っていたのでhttp://localhost:8012/myproject/api/hello にアクセスしてレスポンスが受け取れることを確認します。 終わりに Jenkinsのプラグインを使うことで面倒な作業をスキップできたりするのも魅力だと感じました。 今回の場合はデプロイをプラグインに任せましたが、もしかしたらSSHで接続してってのが必要になったかと思います。 仕事ではGitHubにpushしたらビルドされてました。 基本的な所は学べたかと思います。