前編では、Oracle Database をコンテナ上に起動し、これをグラフ・データベースとして使う方法をご説明しました。この環境だけでも、表データからグラフへの変換やビューの作成、さらには JSON と組み合わせなど、さまざまな利用方法がありますので、おいおいご紹介していきたいと思います。 ここでは、あくまで構築手順だけに絞って、その後半として Graph Server のためのコンテナを追加する方法をご説明します。次のアーキテクチャ図で、既に 2-tier deployment は構築できているので、これから 3-tier deployment を追加します。 Graph Server の構築 Graph Server と Graph Viz が含まれる RPM パッケージをこちらのサイトからダウンロードします。次のパッケージを選択すると、ライセンスへの同意と Oracle アカウントでのログインを要求されます。 Oracle Graph Server 加えて、JDK 11 をこちらのサイトからダウンロードしておきます。こちらも個人用途や開発用途であればライセンス費用がかからないので、安心してお使いいただけます。 Linux - x64 RPM Package ここでダウンロードしたこれらの RPM パッケージと次に作成する Dockerfile を同じディレクトリに配置します。 oracle-graph-21.4.0.x86_64.rpm jdk-11.x.xx_linux-x64_bin.rpm vi Dockerfile Dockerfile FROM oraclelinux:7 ARG VERSION_JDK ARG VERSION_GSC COPY ./jdk-${VERSION_JDK}_linux-x64_bin.rpm /tmp COPY ./oracle-graph-${VERSION_GSC}.x86_64.rpm /tmp RUN yum install -y unzip numactl vim python3 openssl \ && yum clean all \ && rm -rf /var/cache/yum/* \ && rpm -ivh /tmp/jdk-${VERSION_JDK}_linux-x64_bin.rpm \ && rpm -ivh /tmp/oracle-graph-${VERSION_GSC}.x86_64.rpm ENV JAVA_HOME=/usr/java/jdk-${VERSION_JDK} ENV PATH=$PATH:/opt/oracle/graph/bin ENV SSL_CERT_FILE=/etc/oracle/graph/ca_certificate.pem RUN keytool -import -trustcacerts \ -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit \ -alias pgx -file /etc/oracle/graph/ca_certificate.pem -noprompt \ && pip3 install pyjnius EXPOSE 7007 WORKDIR /opt/oracle/graph/bin CMD ["sh", "/opt/oracle/graph/pgx/bin/start-server"] イメージをビルドします。JDK のバージョンは例えば 11.0.13 といったものにおきかえてください。 docker build . \ --tag graph-server:21.4.0 \ --build-arg VERSION_GSC=21.4.0 \ --build-arg VERSION_JDK=<version_of_JDK> イメージが完成したらコンテナを起動します。 docker run \ --name graph-server \ --publish 7007:7007 \ graph-server:21.4.0 データベース接続のための JDBC URL を書き換えます。 docker exec -it graph-server /bin/bash vi /etc/oracle/graph/pgx.conf pgx.conf "jdbc_url": "jdbc:oracle:thin:@host.docker.internal:1521/xepdb1", Graph Server のコンテナを再起動します。 docker restart graph-server Graph Viz にログイン ウェブ・ブラウザから Graph Visualization にログインします。 https://localhost:7007/ui/ 自己署名証明書が使われているため、セキュリティ警告が表示されます。 Chrome: "thisisunsafe" とタイプします Firefox: Advanced > Accept the Risk and continue データベース・ユーザーでログインします。 User: graphuser Password: Welcome1（前編の通りに設定した場合） Advanced Options: Database jdbc:oracle:thin:@host.docker.internal:1521/xepdb1 前編で作成したグラフ GRAPH1 を可視化するため、次の PGQL クエリを実行します。 SELECT v1.name, v2.brand, e.since FROM MATCH (v1)-[e]->(v2) LIMIT 100 ノードやエッジを右クリックするとプロパティの値を確認することができます。 以上で Oracle Graph の環境を作成することができました。この環境を使用して、グラフ・データベースの様々なユースケースを議論していければと思います。

この記事では、laravelで開発したポートフォリオのAWS EC2へのデプロイについて紹介していきます！ 記事が長くなりそうなので、細かい説明とは省いてなるべく実行手順のみ記載していくようにします！ ポートフォリオ使用技術 フロントエンド：HTML5、CSS、bootstrap4.5.0、Tailwindcss2.2.15 バックエンド：PHP7.4.15、Laravel8.34.0、Jetstream1.0、Livewire インフラ：Docker20.10.2、nginx1.18、MySQL8.0.23/phpMyAdmin、Apache2.4.38、AWS S3 デプロイ環境 デプロイ先：AWS EC2 サーバー：nginx（Apacheの場合も記載しました。) 1.AWS EC2 インスタンス作成 1.AWSからログインしてEC2画面にアクセス。 2.画面右上のリージョンを「東京」に。 3.「インスタンスを起動」をクリック。 4.「AWS Linux2」を選択。 5.無料枠の「t2.micro」を選択。→次のステップでステップ5まで移動。 ※ステップ3、4はデフォルトのまま。 6.「タグを追加」→「キー」と「値」を入力。 7.「ルールの追加」→「HTTP」と「HTTPS」を追加→「確認と作成」 8.「起動」 9.「新しいキーペアの作成」→「キーペア名」入力→「キーペアのダウンロード」でローカルに保存→「インスタンスを作成」 10.作成されたインスタンスにチェック→接続 11.10の接続情報を元にターミナルからリモート接続を実施。 $ cd #ターミナルをスタート地点へ $ mkdir ~/.ssh　　　#.sshディレクトリを作成 $ mv Downloads/sample-key.pem .ssh/ #mvコマンドで、「キー.pem」を.sshディレクトリに移動 $ cd .ssh/ #.sshにディレクトリ移動 .ssh $ ls #pemファイルが存在するか確認。「sample-key.pem」が存在すればOK .ssh $ chmod 400 sample-key.pem #キーファイル（○○○.pem）のパーミッションを変更 .ssh $ ssh -i "sample-key.pem" ec2-user@ec2-52-68-186-250.ap-northeast-1.compute.amazonaws.com #ログイン（AWS 接続画面記載のコードをコピペ） Last login: Thu Dec 2 06:14:35 2021 from p3014131-ipoe.ipoe.ocn.ne.jp __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ nginxをセットアップ 今回はnginxをセットアップしますが、Apache2を使用したい方はApache2のインストールを参考にしてください。 Apache2の場合 [ec2-user@ip-172-31-45-44 ~]$ sudo yum update #パッケージアップデート 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 No packages marked for update #「No packages marked for update」は、アップデートするパッケージがないということなのでこのままでOK。 $ sudo yum install apache2 ※初めに選択したAMIがAWS Linux2の場合、aptコマンドが使用できない為、apt→yumに変更してコマンド実行。 nginxの場合 #EC2インスタンスは、nginxのyum intstallが有効になっていない為、有効化。 [ec2-user@ip-172-31-45-44 ~]$ sudo amazon-linux-extras enable nginx1 [ec2-user@ip-172-31-45-44 ~]$ sudo yum -y install nginx #インストール [ec2-user@ip-172-31-45-44 ~]$ nginx -v #バージョン確認 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl enable nginx #nginx自動起動化 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl start nginx.service #起動 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl status nginx.service #起動確認 続く AWSインスタンス一覧画面→作成したインスタンスにチェック→画面下のインスタンス情報内のパブリックIPv4アドレスからアクセス→サーバーの初期画面が表示されればインスタンスの作成とサーバーのセットアップが完了です！ とりあえずここまでお疲れ様でした！ まだ初めの段階ですが、エラーに引っかかってしまうとこれだけの作業でも時間が過ぎてしまいますよね。。 記事が長くなってしまう為、続きはパート2で紹介していきます！ 参考記事

この記事では、laravelで開発したポートフォリオのAWS EC2へのデプロイについて紹介していきます！ 記事が長くなりそうなので、細かい説明とは省いてなるべく実行手順のみ記載していくようにします！ ポートフォリオ使用技術 フロントエンド：HTML5、CSS、bootstrap4.5.0、Tailwindcss2.2.15 バックエンド：PHP7.4.15、Laravel8.34.0、Jetstream1.0、Livewire インフラ：Docker20.10.2、nginx1.18、MySQL8.0.23/phpMyAdmin、Apache2.4.38、AWS S3 デプロイ環境 デプロイ先：AWS EC2 サーバー：nginx（Apacheの場合も記載しました。) 1.AWS EC2 インスタンス作成 1.AWSからログインしてEC2画面にアクセス。 2.画面右上のリージョンを「東京」に。 3.「インスタンスを起動」をクリック。 4.「AWS Linux2」を選択。 5.無料枠の「t2.micro」を選択。→次のステップでステップ5まで移動。 ※ステップ3、4はデフォルトのまま。 6.「タグを追加」→「キー」と「値」を入力。 7.「ルールの追加」→「HTTP」と「HTTPS」を追加→「確認と作成」 8.「起動」 9.「新しいキーペアの作成」→「キーペア名」入力→「キーペアのダウンロード」でローカルに保存→「インスタンスを作成」 10.作成されたインスタンスにチェック→接続 11.10の接続情報を元にターミナルからリモート接続を実施。 $ cd #ターミナルをスタート地点へ $ mkdir ~/.ssh　　　#.sshディレクトリを作成 $ mv Downloads/sample-key.pem .ssh/ #mvコマンドで、「キー.pem」を.sshディレクトリに移動 $ cd .ssh/ #.sshにディレクトリ移動 .ssh $ ls #pemファイルが存在するか確認。「sample-key.pem」が存在すればOK .ssh $ chmod 400 sample-key.pem #キーファイル（○○○.pem）のパーミッションを変更 .ssh $ ssh -i "sample-key.pem" ec2-user@ec2-52-68-186-250.ap-northeast-1.compute.amazonaws.com #ログイン（AWS 接続画面記載のコードをコピペ） Last login: Thu Dec 2 06:14:35 2021 from p3014131-ipoe.ipoe.ocn.ne.jp __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ nginxをセットアップ 今回はnginxをセットアップしますが、Apache2を使用したい方はApache2のインストールを参考にしてください。 Apache2の場合 [ec2-user@ip-172-31-45-44 ~]$ sudo yum update #パッケージアップデート 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 No packages marked for update #「No packages marked for update」は、アップデートするパッケージがないということなのでこのままでOK。 $ sudo yum install apache2 ※初めに選択したAMIがAWS Linux2の場合、aptコマンドが使用できない為、apt→yumに変更してコマンド実行。 nginxの場合 #EC2インスタンスは、nginxのyum intstallが有効になっていない為、有効化。 [ec2-user@ip-172-31-45-44 ~]$ sudo amazon-linux-extras enable nginx1 [ec2-user@ip-172-31-45-44 ~]$ sudo yum -y install nginx #インストール [ec2-user@ip-172-31-45-44 ~]$ nginx -v #バージョン確認 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl enable nginx #nginx自動起動化 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl start nginx.service #起動 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl status nginx.service #起動確認 続く AWSインスタンス一覧画面→作成したインスタンスにチェック→画面下のインスタンス情報内のパブリックIPv4アドレスからアクセス→サーバーの初期画面が表示されればインスタンスの作成とサーバーのセットアップが完了です！ とりあえずここまでお疲れ様でした！ まだ初めの段階ですが、エラーに引っかかってしまうとこれだけの作業でも時間が過ぎてしまいますよね。。 記事が長くなってしまう為、続きはパート2で紹介していきます！ 参考記事

PHP 8.1 がリリース！ 2021年11月25日に PHP 8.1 がリリースされました enum の追加や readonly プロパティが設定できるなど、嬉しい機能が盛りだくさんですね。 詳しい内容は既に記事がありますので、ぜひそちらをご覧ください（感謝！ ）。 Laravel の対応は？ 普段は Laravel をメインで使っていますので、 PHP 8.1 の恩恵を受けるためには Laravel のバージョンアップをしなければなりません。 Github を見ると、2021/10/22 リリースの v8.67.0 からサポートされているようです。 ただ、依存パッケージが対応しているかなどは調査が必要ですし、リリース済のコードだと尚更気軽にバージョンアップはできないです。 つまりプロジェクトによってはあまり関係ない...そんなふうに考えていた時期が僕にもありました。 一方その頃... それはいつも通りチームメンバーが PHP 8.0 × Laravel v8.33.1 環境で CD/CI を回したときでした。 急に CD/CI が泡を吹いて倒れたのです。 エラーログ Fatal error: During inheritance of ArrayAccess: Uncaught ErrorException: Return type of Illuminate\Support\Collection::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in vendor/laravel/framework/src/Illuminate/Collections/Collection.php:1411 みたことないエラーだったので、パッと見は原因がわかりませんでした。 ちょっと前までは元気に動いていたのに一体どうして... ただ、幸いにも原因はすぐに目星がつきました。 原因は composer の docker image このエラーはバックエンドのビルド時に起きたもので、そこでは Docker で composer:2 というイメージを使用していました。 このイメージの中で使用されている PHP のバージョンが 8.1 に上げられたことが原因でした。 イメージを composer:2.1.11 に指定したところ、無事にビルドが通るようになりました。 composer:2.1.12 以降は PHP 8.1 を使うようになっているようなので、しばらくは注意が必要です。 教訓 Docker のイメージはちゃんとマイナーバージョンまで指定した方がいいですね。 あと今回は PHP 8.1 がリリースされたことを知っていたことが大きく、エラーになったタイミングとリリースされた日が近かったので目星がつき、早期の解決につながりました。 自分が使っている技術については最新情報をキャッチアップすることが大事だと改めて認識しました。

初めての投稿　+ 全然知識ない学生なので間違えてるところあったらコメントで教えていただけると嬉しいです。 読みにくかったらすみません... 作るもの 簡単な日記アプリ(というかブログ？) 全体を通してすること フロントエンド Next.jsを使ってSPAを作成し、Vercelにデプロイする。 バックエンド 1.dockerを使ってNginx + Mysql8.0 + Python3.9の環境を構築する。 2.simpleJWT + dj_rest_authを使ってJWTを用いたログイン、ログアウト、リフレッシュ機能を作成する。 3.allauth + sendgridを使ってユーザー登録時に本登録のメールが送られてくるようにする。 4.日記の一覧取得、詳細取得の機能を作成する。 インフラ EC2,ELB,S3,RDS,Route53などを使ってインフラを構築し、作成したAPIをデプロイする。 ELBにはSSL証明書を発行し、80番ポートへのアクセスは443番ポートに転送するようにする。 今回すること 1.dockerを使ってNginx + Mysql8.0 + Python3.9の環境を構築する。 早速やっていきます。 開発の段階ではdocker-compoesを使うことにします。 まずはshellからプロジェクト用のディレクトリを作成して、移動します。 home/ mkdir my_diary&&cd $_ PythonのDockerfileを作成します。 Pythonという名前のディレクトリを作成してその中にDockerfileを作ることにします。 my_diary/ mkdir python&&cd $_ vim Dockerfile Dockerfileを書いていきます。 my_diary/python/Dockerfile FROM python:3.9 # アプリケーションのログをリアルタイムでshellから確認するため ENV PYTHONUNBUFFERED 1 # pycファイルは邪魔なので生成させないようにする ENV PYTHONDONTWRITEBYTECODE 1 # コンテナ内にmy_diaryディレクトリを作成して、移動する RUN mkdir /my_diary WORKDIR /my_diary # ローカルのrequirements-dev.txtをコンテナ内のmy_diaryディレクトリに追加する # その後、ファイルに書いてあるモジュールを全てinstallする ADD requirements-dev.txt /my_diary/ RUN pip install -r requirements-dev.txt ADD . /my_diary/ 次にアプリケーション作成に必要なサードパーティモジュールをrequirements-dev.txtに書いていきます。 認証周りや、画像を扱うときに必要なモジュール、その他諸々をinstallします。 my_diary/python/requirements-dev.txt Django==3.2.5 django-allauth==0.44.0 django-cors-headers==3.7.0 django-imagekit==4.0.2 djangorestframework==3.12.2 djangorestframework-simplejwt==4.6.0 django-rest-auth==0.9.5 django-environ==0.8.1 django_cleanup==5.2.0 dj-rest-auth==2.1.4 uwsgi==2.0.19.1 mysqlclient==2.0.3 Pillow==8.4.0 pycryptodome==3.10.1 これでPythonのDockerfileの作成は完了です。 次はNginxの設定ファイルを書いていきます。 my_diaryディレクトリに戻ってnginxディレクトリを作成し、移動します。 my_diary/ mkdir nginx&&cd $_ uwsgi_paramsというファイルを作成し、wsgiがnginxから受け取る値を設定します。 uwsgi_params uwsgi_param QUERY_STRING $query_string; uwsgi_param REQUEST_METHOD $request_method; uwsgi_param CONTENT_TYPE $content_type; uwsgi_param CONTENT_LENGTH $content_length; uwsgi_param REQUEST_URI $request_uri; uwsgi_param PATH_INFO $document_uri; uwsgi_param DOCUMENT_ROOT $document_root; uwsgi_param SERVER_PROTOCOL $server_protocol; uwsgi_param REQUEST_SCHEME $scheme; uwsgi_param HTTPS $https if_not_empty; uwsgi_param REMOTE_ADDR $remote_addr; uwsgi_param REMOTE_PORT $remote_port; uwsgi_param SERVER_PORT $server_port; uwsgi_param SERVER_NAME $server_name; confというディレクトリを作成して、その下にnginxの設定ファイルを作成します。 my_diary/nginx mkdir conf&&$_ vim nginx.conf my_diary/nginx/conf/nginx.conf upstream django { ip_hash; server python:8080; } server { listen 8000; server_name 127.0.0.1; charset utf-8; location /static { alias /static; } location / { uwsgi_pass django; include /etc/nginx/uwsgi_params; } server_tokens off; } これでnginxの設定も完了しました。 次にmysqlの設定をしていきます。 一旦my_dairyディレクトリに戻り、sqlディレクトリを作成して移動します。 その下に設定ファイルを作成し、djangoのテスト時にDB作成を許可するようにします。 my_diary/ mkdir sql&&$_ vim init.sql my_diary/sql/init.sql GRANT ALL PRIVILEGES ON test_my_diary.* TO 'user'@'%'; FLUSH PRIVILEGES; 次にMysql8.0のパスワードの設定や、文字コードの設定をします。 my_diary/ mkdir sqlcnf&&$_ vim my.cnf my_diary/sqlcnf/my.cnf [client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqldump] default-character-set=utf8 [mysqld] character-set-server=utf8 default_authentication_plugin=mysql_native_password これでsqlの設定も完了です。 最後にdocekr-compose.ymlを作成します。 my_diary vim docker-compose.yml my_diary/docker-compose.yml version: "3.7" services: nginx: image: nginx:1.21.1 ports: - "8000:8000" volumes: - ./nginx/conf:/etc/nginx/conf.d - ./nginx/uwsgi_params:/etc/nginx/uwsgi_params - ./static:/static depends_on: - python db: image: mysql:8.0 ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: my_diary MYSQL_USER: hoge MYSQL_PASSWORD: hogehoge TZ: "Asia/Tokyo" volumes: - ./mysql:/var/lib/mysql - ./sql:/docker-entrypoint-initdb.d - ./sqlcnf:/etc/mysql/conf.d/my.cnf python: build: ./python command: uwsgi --socket :8080 --module config.wsgi --py-autoreload 1 --logto /tmp/mylog.log volumes: - ./src:/my_diary - ./static:/static - ./media:/media expose: - "8080" depends_on: - db これで環境構築は完了しました。 こんな感じの構成になってれば大丈夫だと思います。 my_diary/ | |--nginx | |--uwsgi_params | |--conf | |--nginx.conf | |--python | |--Dockerfile | |--requirements-dev.txt | |--sql | |--init.sql | |--sqlcnf | |--my.cnf | |--docker-compose.yml 次に動作確認のためにDjangoのプロジェクトを作成してみましょう。 my_diary docker-compose run python django-admin startproject config . 最後にdockerを立ち上げてlocalhost:8000にアクセスしてみてください。 my_diary docker-compose up ロケットが飛んでる画面が出てきたら成功です。 初めて記事を書いてみて 飽きました... それと、少ししか描いてないのに結構な時間がかかりました。 デプロイするところまでやろうと思ってたけど、多分もう描かなさそう...

初めての投稿　+ 全然知識ない学生なので間違えてるところあったらコメントで教えていただけると嬉しいです。 読みにくかったらすみません... 全体を通してすること フロントエンド Next.jsを使ってSPAを作成し、Vercelにデプロイする。 バックエンド 1.dockerを使ってNginx + Mysql8.0 + Python3.9の環境を構築する。 2.simpleJWT + dj_rest_authを使ってJWTを用いたログイン、ログアウト、リフレッシュ機能を作成する。 3.allauth + sendgridを使ってユーザー登録時に本登録のメールが送られてくるようにする。 4.日記の一覧取得、詳細取得の機能を作成する。 インフラ EC2,ELB,S3,RDS,Route53などを使ってインフラを構築し、作成したAPIをデプロイする。 ELBにはSSL証明書を発行し、80番ポートへのアクセスは443番ポートに転送するようにする。 今回すること 1.dockerを使ってNginx + Mysql8.0 + Python3.9の環境を構築する。 早速やっていきます。 開発の段階ではdocker-compoesを使うことにします。 まずはshellからプロジェクト用のディレクトリを作成して、移動します。 home/ mkdir my_diary&&cd $_ PythonのDockerfileを作成します。 Pythonという名前のディレクトリを作成してその中にDockerfileを作ることにします。 my_diary/ mkdir python&&cd $_ vim Dockerfile Dockerfileを書いていきます。 my_diary/python/Dockerfile FROM python:3.9 # アプリケーションのログをリアルタイムでshellから確認するため ENV PYTHONUNBUFFERED 1 # pycファイルは邪魔なので生成させないようにする ENV PYTHONDONTWRITEBYTECODE 1 # コンテナ内にmy_diaryディレクトリを作成して、移動する RUN mkdir /my_diary WORKDIR /my_diary # ローカルのrequirements-dev.txtをコンテナ内のmy_diaryディレクトリに追加する # その後、ファイルに書いてあるモジュールを全てinstallする ADD requirements-dev.txt /my_diary/ RUN pip install -r requirements-dev.txt ADD . /my_diary/ 次にアプリケーション作成に必要なサードパーティモジュールをrequirements-dev.txtに書いていきます。 認証周りや、画像を扱うときに必要なモジュール、その他諸々をinstallします。 my_diary/python/requirements-dev.txt Django==3.2.5 django-allauth==0.44.0 django-cors-headers==3.7.0 django-imagekit==4.0.2 djangorestframework==3.12.2 djangorestframework-simplejwt==4.6.0 django-rest-auth==0.9.5 django-environ==0.8.1 django_cleanup==5.2.0 dj-rest-auth==2.1.4 uwsgi==2.0.19.1 mysqlclient==2.0.3 Pillow==8.4.0 pycryptodome==3.10.1 これでPythonのDockerfileの作成は完了です。 次はNginxの設定ファイルを書いていきます。 my_diaryディレクトリに戻ってnginxディレクトリを作成し、移動します。 my_diary/ mkdir nginx&&cd $_ uwsgi_paramsというファイルを作成し、wsgiがnginxから受け取る値を設定します。 uwsgi_params uwsgi_param QUERY_STRING $query_string; uwsgi_param REQUEST_METHOD $request_method; uwsgi_param CONTENT_TYPE $content_type; uwsgi_param CONTENT_LENGTH $content_length; uwsgi_param REQUEST_URI $request_uri; uwsgi_param PATH_INFO $document_uri; uwsgi_param DOCUMENT_ROOT $document_root; uwsgi_param SERVER_PROTOCOL $server_protocol; uwsgi_param REQUEST_SCHEME $scheme; uwsgi_param HTTPS $https if_not_empty; uwsgi_param REMOTE_ADDR $remote_addr; uwsgi_param REMOTE_PORT $remote_port; uwsgi_param SERVER_PORT $server_port; uwsgi_param SERVER_NAME $server_name; confというディレクトリを作成して、その下にnginxの設定ファイルを作成します。 my_diary/nginx mkdir conf&&$_ vim nginx.conf my_diary/nginx/conf/nginx.conf upstream django { ip_hash; server python:8080; } server { listen 8000; server_name 127.0.0.1; charset utf-8; location /static { alias /static; } location / { uwsgi_pass django; include /etc/nginx/uwsgi_params; } server_tokens off; } これでnginxの設定も完了しました。 次にmysqlの設定をしていきます。 一旦my_dairyディレクトリに戻り、sqlディレクトリを作成して移動します。 その下に設定ファイルを作成し、djangoのテスト時にDB作成を許可するようにします。 my_diary/ mkdir sql&&$_ vim init.sql my_diary/sql/init.sql GRANT ALL PRIVILEGES ON test_my_diary.* TO 'user'@'%'; FLUSH PRIVILEGES; 次にMysql8.0のパスワードの設定や、文字コードの設定をします。 my_diary/ mkdir sqlcnf&&$_ vim my.cnf my_diary/sqlcnf/my.cnf [client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqldump] default-character-set=utf8 [mysqld] character-set-server=utf8 default_authentication_plugin=mysql_native_password これでsqlの設定も完了です。 最後にdocekr-compose.ymlを作成します。 my_diary vim docker-compose.yml my_diary/docker-compose.yml version: "3.7" services: nginx: image: nginx:1.21.1 ports: - "8000:8000" volumes: - ./nginx/conf:/etc/nginx/conf.d - ./nginx/uwsgi_params:/etc/nginx/uwsgi_params - ./static:/static depends_on: - python db: image: mysql:8.0 ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: my_diary MYSQL_USER: hoge MYSQL_PASSWORD: hogehoge TZ: "Asia/Tokyo" volumes: - ./mysql:/var/lib/mysql - ./sql:/docker-entrypoint-initdb.d - ./sqlcnf:/etc/mysql/conf.d/my.cnf python: build: ./python command: uwsgi --socket :8080 --module config.wsgi --py-autoreload 1 --logto /tmp/mylog.log volumes: - ./src:/my_diary - ./static:/static - ./media:/media expose: - "8080" depends_on: - db これで環境構築は完了しました。 こんな感じの構成になってれば大丈夫だと思います。 my_diary/ | |--nginx | |--uwsgi_params | |--conf | |--nginx.conf | |--python | |--Dockerfile | |--requirements-dev.txt | |--sql | |--init.sql | |--sqlcnf | |--my.cnf | |--docker-compose.yml 次に動作確認のためにDjangoのプロジェクトを作成してみましょう。 my_diary docker-compose run python django-admin startproject config . 最後にdockerを立ち上げてlocalhost:8000にアクセスしてみてください。 my_diary docker-compose up ロケットが飛んでる画面が出てきたら成功です。 初めて記事を書いてみて 飽きました... それと、少ししか描いてないのに結構な時間がかかりました。 デプロイするところまでやろうと思ってたけど、多分もう描かなさそう...

[概要] ③docker-compose.ymlファイルの作成編の後続記事となります。 　docker-compose.ymlファイルの作成編 [作業] [現在のディレクトリ構成] LocalServer/ ├── app/ └── Dockerfile └── docker-compose.yml pythonファイルの作成目的 そもそもの目的は、Dockerを使用して検証用サーバーを構築すること。 だけでなく、その検証用サーバーに対して、リクエストからレスポンスまでを一貫して行えることが 目的です。 なので、今回はpythonを使用して、検証用サーバーでの処理を記述します。 ※pythonは使ってみたかったからです。はいw pythonファイルの作成 1, ファイル名「local_server.py」を以下の内容で作成する。 local_server.py from flask import Flask app = Flask(__name__) ############################################################################# ### ローカルサーバー ############################################################################# ### ### テスト用に文字を返却するだけのメソッド ### @app.route('/') def get_text(): return 'リクエスト成功！！' <記述内容の詳細> 1行目 from flask import Flask # Flaskのimport文 2行目 app = Flask(__name__) # Flaskのインスタンス生成 11~13行目 @app.route('/test') def get_text(): return 'リクエスト成功！！' # @app.route('/'): URLとメソッドを紐付ける役割(例：http://ipアドレス/test) # def get_text(): メソッド定義 # return 'リクエスト成功！！': 文字列の返却 2, 上記ファイルを作成したら、[LocalServer/app]フォルダ直下に保存しよう。 LocalServer / app / local_server.py [参考] ・ https://docs.docker.jp/compose/overview.html

[概要] docker-compose.ymlファイル作成編の後続記事となります。 ③ docker-compose.ymlファイル作成編 [作業] [現在のディレクトリ構成] LocalServer/ ├── app/ └── Dockerfile └── docker-compose.yml pythonファイルの作成目的 そもそもの目的は、Dockerを使用して検証用サーバーを構築すること。 だけでなく、その検証用サーバーに対して、リクエストからレスポンスまでを一貫して行えることが 目的です。 なので、今回はpythonを使用して、検証用サーバーでの処理を記述します。 ※pythonは使ってみたかったからです。はいw pythonファイルの作成 1, ファイル名「local_server.py」を以下の内容で作成する。 local_server.py from flask import Flask app = Flask(__name__) ############################################################################# ### ローカルサーバー ############################################################################# ### ### テスト用に文字列を返却するだけのメソッド ### @app.route('/') def get_text(): return 'リクエスト成功！！' <記述内容の詳細> 1行目 from flask import Flask # Flaskのimport文 2行目 app = Flask(__name__) # Flaskのインスタンス生成 11~13行目 @app.route('/test') def get_text(): return 'リクエスト成功！！' # @app.route('/'): URLとメソッドを紐付ける役割(例：http://ipアドレス/test) # def get_text(): メソッド定義 # return 'リクエスト成功！！': 文字列の返却 2, 上記ファイルを作成したら、[LocalServer/app]フォルダ直下に保存しよう。 LocalServer / app / local_server.py [次のページ] ⑤ 最終章 実行編

前提条件 OS MacOS Monterey 12.0.1 CPU Apple M1(arm64) Docker Docker Desktop 4.2.0 (70708) CentOS CentOS Linux release 7.9.2009 (AltArch) ※Dockerで構築したCentOS環境で、シェルスクリプトの作成練習をしています。 やりたいこと １　変数varに引数を渡す ２　条件分岐させ、渡した引数が　　 　①自分の名前なら「お前の名前だな」 　②それ以外なら「誰だお前は？」 　　と返事させる というしょーもない練習用のシェルスクリプトを作ります。 つまづいた話 半角スペースの有無が原因で動作せず地味にハマったので、備忘録がてら。ちょいネタです。 ※記事の最後に、半角スペース云々以外で「実行権限付与」(注意点１)と「ファイル名を指定して実行」（注意点２）を載せてます。参考までに。 正しい例 #!/bin/bash # ※※このvarに注目！！ var=$1 if [ $var = "ryohey" ]; then echo 'This is your name.' else echo 'Who are you?' fi if文の書き方・シェルスクリプトの書き方については、ここでは省略します。 自分の名前を入力すれば、 [Udemy@0a412e1af0a1 ~]$ ./base6_test.sh ryohey This is your name. それ以外のことを入力すると、 [Udemy@0a412e1af0a1 ~]$ ./base6_test.sh qiita Who are you? 欲しい返事をくれます。 誤った例 #!/bin/bash # ※※varや＝の後に半角スペースを入れた場合！！ var = $1 if [ $var = "ryohey" ]; then echo 'This is your name.' else echo 'Who are you?' fi ○正しい例） var=$1 ×誤った例） var = $1 こうしてしまうと、自分の名前を打っているにもかかわらず、 [Udemy@0a412e1af0a1 ~]$ ./base6_test.sh ryohey ./base6_test.sh: line 3: var: command not found ./base6_test.sh: line 5: [: =: unary operator expected Who are you? エラーを吐かれ、「お前は誰だ？」の方が出力されてしまいます。 半角スペースの有無だけの違いですが、スペースを入れたことで、varが変数varだと認識されなくなったようです。 気付くまで数分かかったので一応記事にしました。 お役に立てれば幸いです。 不適当な説明などあれば、ご指摘ください。 ありがとうございましたm(_ _)m 注意点１ 作成したシェルスクリプトは、忘れずに実行権限を付与してから実行してください。 [Udemy@0a412e1af0a1 ~]$ chmod 755 base6_test.sh chmodコマンド 　　(CHange MODe) アクセス権を変更するコマンドです。ここではchmodの後に「755」を続けることで、所有者に実行権（'x'で表されます）を付与しています。 以下で確認します。 [Udemy@0a412e1af0a1 ~]$ ls -l base6_test.sh -rwxr-xr-x 1 Udemy Udemy 113 Dec 2 07:29 base6_test.sh -rwxr 　　↑一番最初のこの「x」です。x=eXecute(実行)権限があるということです。 もし実行権限を付与しないまま実行しようとすると、 [Udemy@0a412e1af0a1 ~]$ ./base6_test.sh ryohey -bash: ./base6_test.sh: Permission denied 権限がないと怒られます。 ※パーミッションの管理について、ここでは割愛します。 注意点２ 作成したシェルスクリプトを実行するときは、相対パス（または絶対パス）でファイル名を指定しないと、動いてくれません。 ※パス指定しない場合、 [Udemy@0a412e1af0a1 ~]$ base6_test.sh ryohey -bash: base6_test.sh: command not found ファイルが見つかりませんので、以下のように指定します。 相対パス [Udemy@0a412e1af0a1 ~]$ ./base6_test.sh ryohey This is your name. 絶対パス [Udemy@0a412e1af0a1 ~]$ /home/Udemy/base6_test.sh ryohey This is your name. 参考文献

[概要] ②Dockerファイルの作成編の後続記事となります。 　Dockerファイルの作成編 当記事は、docker-compose.ymlファイルを作成する記事となり、 不要と思われる方は飛ばしてもらえればと思います。 [作業] [現在のディレクトリ構成] LocalServer/ ├── app/ └── Dockerfile docker-composeのインストール確認 Dockerをインストールされている方は、dokcer-composeもインストールされている筈ですが、 確認方法としては以下のコマンドで、バージョンが表示されれば、とりあえずOKです。 terminal $ docker-compose -v docker-compose.ymlファイルとは Dockerファイルから成る、複数のコンテナを定義し実行する Docker アプリケーションのためのツールです。 簡単に、申し上げるとdokcer-compose.ymlファイルを実行すれば、1個1個のコンテナを起動させる手間がなくなるイメージ。 ※今回は、起動するコンテナは1つですが、学びのため使用 docker-compose.ymlファイルの作成 1, テキストファイルで、ファイル名「docker-compose.yml」を以下の内容で作成する。 docker-compose.yml version: '3.3' services: flask: build: . ports: - 8080:8080 volumes: - ./app:/app environment: TZ: Asia/Tokyo FLASK_APP: local_server.py FLASK_ENV: development restart: 'no' command: flask run --host 0.0.0.0 --port 8080 <命令文> services:お決まりの記述で、servicesの内容をネストして以下を記述しよう 　flask: 今回使用するサービス（pythonのフレームワーク）でネストして以下を記述しよう 　　build：Dockerファイルのあるディレクトリを指す 　　　　　※ピリオドなので、カレントディレクトリを指している　-> docker-compose.ymlファイルと同じ階層 　　ports：Dockerコンテナを立ち上げる際のポート番号 　　volumes：マウントする設定ファイルのパスを指定 　　　　　　　※マウント：使える状態にさせること　　　 　　environment：環境変数設定(パスワードなど) 　　　　　　　　　TZ: Asia/Toyko 　　　　　　　　　※タイムゾーンの指定 　　　　　　　　 　　　　　　　　　FLASK_APP: local_server.py 　　　　　　　　　※インスタンスの場所を指定（pythonファイルを指定） 　　　　　　　　　FLASK_ENV: development 　　　　　　　　　※flaskをデバッグモードで起動（ソースコードを変更したとき再読み込みする機能） 　　　　　　　 　　restart：自動起動設定 　　　　　　※noにしてあげることで、勝手に起動することを防ぐ。 　　command：コマンド 2, 上記ファイルを作成したら、[LocalServer]フォルダ直下に保存しよう。 LocalServer / docker-compose.yml [参考] ・ https://docs.docker.jp/compose/overview.html

[概要] Dockerファイル作成編の後続記事となります。 ② Dockerファイル作成編 当記事は、docker-compose.ymlファイルを作成する記事となり、 不要と思われる方は飛ばしてもらえればと思います。 [作業] [現在のディレクトリ構成] LocalServer/ ├── app/ └── Dockerfile docker-composeのインストール確認 Dockerをインストールされている方は、dokcer-composeもインストールされている筈ですが、 確認方法としては以下のコマンドで、バージョンが表示されれば、とりあえずOKです。 terminal $ docker-compose -v docker-compose.ymlファイルとは Dockerファイルから成る、複数のコンテナを定義し実行する Docker アプリケーションのためのツールです。 簡単に、申し上げるとdokcer-compose.ymlファイルを実行すれば、1個1個のコンテナを起動させる手間がなくなるイメージ。 ※今回は、起動するコンテナは1つですが、学びのため使用 docker-compose.ymlファイルの作成 1, テキストファイルで、ファイル名「docker-compose.yml」を以下の内容で作成する。 docker-compose.yml version: '3.3' services: flask: build: . ports: - 8080:8080 volumes: - ./app:/app environment: TZ: Asia/Tokyo FLASK_APP: local_server.py FLASK_ENV: development restart: 'no' command: flask run --host 0.0.0.0 --port 8080 <命令文> services:お決まりの記述で、servicesの内容をネストして以下を記述しよう 　flask: 今回使用するサービス（pythonのフレームワーク）でネストして以下を記述しよう 　　build：Dockerファイルのあるディレクトリを指す 　　　　　※ピリオドなので、カレントディレクトリを指している　-> docker-compose.ymlファイルと同じ階層 　　ports：Dockerコンテナを立ち上げる際のポート番号 　　volumes：マウントする設定ファイルのパスを指定 　　　　　　　※マウント：使える状態にさせること　　　 　　environment：環境変数設定(パスワードなど) 　　　　　　　　　TZ: Asia/Toyko 　　　　　　　　　※タイムゾーンの指定 　　　　　　　　 　　　　　　　　　FLASK_APP: local_server.py 　　　　　　　　　※インスタンスの場所を指定（pythonファイルを指定） 　　　　　　　　　FLASK_ENV: development 　　　　　　　　　※flaskをデバッグモードで起動（ソースコードを変更したとき再読み込みする機能） 　　　　　　　 　　restart：自動起動設定 　　　　　　※noにしてあげることで、勝手に起動することを防ぐ。 　　command：コマンド 2, 上記ファイルを作成したら、[LocalServer]フォルダ直下に保存しよう。 LocalServer / docker-compose.yml [次のページ] ④ pythoneファイル作成編 [参考] ・ https://docs.docker.jp/compose/overview.html

前提条件 OS MacOS Monterey 12.0.1 CPU Apple M1(arm64) Docker Docker Desktop 4.2.0 (70708) CentOS CentOS Linux release 7.9.2009 (AltArch) やりたいこと Dockerで構築したCentOS７の環境で、ネットワーク周りの確認ができるipコマンドを実行したい つまづいた話 ipコマンドを実行しようとしたら、そんなものは無いと怒られる [root@0a412e1af0a1 /]# ip addr bash: ip: command not found 単純に↓こんなのでいいかなとも思いましたが、ダメみたい。。。 [root@0a412e1af0a1 /]# yum install ip # 中略 No package ip available. Error: Nothing to do どうやらDockerの公式イメージなので、パッケージには最低限の内容しか入っていないようです。 解決策 「iproute」をインストール ※ちなみに、「net-tools」というやつは、今はもう非推奨とのことです。 [root@0a412e1af0a1 /]# yum install iproute ipコマンドを試してみる ip addr [IP ADDRESS] 　インターフースの状態やIPアドレスを表示 [root@0a412e1af0a1 /]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000 link/tunnel6 :: brd :: 10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever ip route 　ルーティングテーブルを表示 [root@0a412e1af0a1 /]# ip route default via 172.17.0.1 dev eth0 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.3 おまけ（pingコマンド） ping -c パケット送信回数 n.n.n.n（送信先IPアドレス） ネットワークの通信確認コマンドです。 　※　cオプションで回数を設定しないと、パケットを送り続けることになってしまいます。 [root@0a412e1af0a1 /]# ping -c 3 192.168.73.92 PING 192.168.73.92 (192.168.73.92) 56(84) bytes of data. 64 bytes from 192.168.73.92: icmp_seq=1 ttl=37 time=1.44 ms 64 bytes from 192.168.73.92: icmp_seq=2 ttl=37 time=1.29 ms 64 bytes from 192.168.73.92: icmp_seq=3 ttl=37 time=1.26 ms 自分のスマホでテザリング接続していたので、そのネットワークのIPアドレスに向けてpingを打ってみました。パケット送信回数は３回。 （IPアドレスは、Mac右上のバーから「”ネットワーク”環境設定」を開くと見れます）

この記事は シーエー・アドバンス Advent Calendar 2021 2日目の記事です。 前回の記事は @toubaruさんの 「macOS Catalina に Frida をインストールする」 でした。 明日の記事は @Jeyさんです。 普段、脆弱性診断のクロール業務をしています。 開発研修として、Laravelでの開発があり、今回はDockerの知識があまりない人でも Laravel公式が出しているsailというものを使って環境構築できるようにまとめてみました。 Laravel Sailでは現時点では未サポートのPhpMyAdminを研修では使ったりもするため（Dockerの知識がちょっと必要）追加で記載しています。 概要 Laravel公式から出ているsailが、最近Dockerの知識がない初心者でも環境構築が楽にできる とLaravelやPHP勉強会で耳にしたので気になったので試してみました。 また、社内研修で素のPHPでサイト作成後、Laravelでのサイト作成もあるため、 今後Dockerの知識がない人でもサクッと簡単に環境構築できるかと思い、試してことをまとめてみました。 動作検証環境 Mac Book Pro16(Intel) OS catalina（バージョン10.15.7） Docker Desktop（バージョン3.5.2） 準備 Docker Desktop導入がまだの人はインストールしてください。 これまでのLaravel導入手段まとめ これまで、Laravel導入手段はLaravel非公式のもので様々な方法がありました。 PHPバージョン8以降から、Laravel公式からLaravel Sailが登場し、手軽にLaradockの環境構築ができるようになりました。 Docker系 Laravel Sail curlコマンドでLaradock環境を構築できる。 PHPのバージョンはデフォルトだと8.0 現在Sailが使用できるPHPバージョンは、 8.1、 8.0 、 7.4の3つ。 curlコマンドにwith -mysql等、引数を追加することでサービスの指定もできる。 指定可能なサービスは下記9つ。 mysql pgsql mariadb redis memcached meilisearch minio selenium mailhog サービス指定しない場合のデフォルトで導入されるサービスは下記5つ mysql redis meilisearch mailhog selenium Laradock Laradock - github 全部入りのLaravel Docker環境 Laravel非公式 設定ファイルをいじることで独自の好きな環境を作れる Vessel PHP バージョンは7.4で止まってそう PHP 7.4 MySQL 5.7 Redis (latest) NodeJS (latest), with NPM, Yarn, & Gulp dockerコマンドやdocker-composeコマンドも使えるけれど、vesselコマンドでも動くらしい。参考：VesselでLaravelのDocker環境をサクッと作る - Qiita記事 docker-laravel ucanさんという方が作成したLaravel開発環境 最低限のLaravel開発環境が作成できる Qiitaに手順の解説あり ローカル系 PHPとComposerをローカルインストール - Laravel日本語ドキュメント Laravel Sailで環境構築 1.Docker Desktop導入が完了したら、ターミナルを開き、作成したい任意の場所に移動します。 　（今回はデスクトップに作成します。$の後からコマンド入力してください） Terminal $ cd /Users/[自分のPC名]/Desktop 確認方法： Terminal $ pwd #`pwd`コマンド実施後、下記のように返ってきたらOK。 /Users/[自分のPC名]/Desktop [自分のPC名] Desktop 2.下記curlコマンドを叩く。今回はexample-appという名前で作成してます。 Terminal $ curl -s "https://laravel.build/example-app" | bash 3.example-appに移動し、下記コマンドでSailの開始する Terminal $ cd example-app $ ./vendor/bin/sail up -d 4.Sail開始後、localhostにアクセスし、Laravelの画面が表示されたらLaravel導入成功。 5.下記コマンドで一旦、Sail停止します。 Terminal $ ./vendor/bin/sail stop ※Bashエイリアスの設定 上記コマンドを短縮したい場合は、エイリアス設定しておくとsail up、sail stopとsailコマンドで操作ができる。 Terminal $ alias sail='[ -f sail ] && bash sail || bash vendor/bin/sail' Docker起動の度に、上記エイリアス設定しないとSailコマンドが使えないので注意。 Dockerで永続的にエイリアス設定する方法をご存知の方がいれば、コメントで教えていただけると嬉しいです。 6.初回起動時に.env.exampleファイルが作成されているかと思うので、自分の環境様様に.envとしてコピーします Terminal $ .env.example .env 7.上記⑥でコピーした.envファイルの5行目（APP_URL=）の下にLaravelのポート番号を追記する .env APP_PORT=8777 8.上記手順③、④を再度実施し、Laravel sail起動後、http://localhost:8777/ へアクセスし、Laravelの画面が表示されたら設定完了です。 phpMyAndmiｎを追加する Sailは単なるDockerであるため、Sailに関するほぼすべてを自由にカスタマイズできます。 公式でPhpMyAndminはサポートしてない。 公式に上記の記載があったので、通常のDockerでPhpMyAdminを使用する時と同じ様にdocker-compose.ymlファイルに追記していきます。 Sailを起動している場合、./vendor/bin/sail stopかsail stopで一旦Sailを停止します。 docker-compose.ymlのmysqlの下あたりにPhpMyAdminを追記する。（インデント等も同じになるよう記載してください） docker-compose.yml phpmyadmin: image: phpmyadmin/phpmyadmin links: - mysql:mysql ports: - 8888:80 environment: MYSQL_USERNAME: '${DB_USERNAME}' MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}' PMA_HOST: mysql networks: - sail 3.PhpMyAdminでログインする際に、データベースのログイン情報が必要なので、データベース情報を追記します。 .env DB_CONNECTION=mysql DB_HOST=mysql DB_PORT=8888 # []内は自分が作成したデータベース名を記述する DB_DATABASE=[example-app] # []内は自分が作成したデータベースのユーザー名を入力する DB_USERNAME=[username] # []内は自分が作成したUserのパスワード入力する DB_PASSWORD=[password] 4.http://localhost:8888/index.phpにアクセスし、データベースのログイン情報を入力しPhpMyAdminにログインできれば完了です。 最終確認 最後にphpMyAndminとLaravel画面が表示されるか確認し、それぞれのページが表示されれば環境構築終了。 Laravel phpMyAndmin この後のLaravelを使ってのサイト作成は通常のLaravelと基本的には同じです。 BurpSuite等のプロキシツールでLaravelアプリの通信を取得したい場合 上記、Laravelで設定したlocalhostのポート番号8777で通信取得できます。 まとめ Laravel公式がサポートしている範囲内であれば、Sailを使ったLaravelの環境構築を爆速で行えるということが分かりました。 Intel Macを持っている初心者の人であれば、curlコマンドを叩くだけでLaravelの環境構築ができてしまうので Laravelの環境構築でつまずくことは、大分減りそうかな。と思いました。 公式がサポートしていないサービスを使いたい等、自分でSailに追加してオリジナルで環境構築を行う場合は、 .ymlファイルやDB作成時の記載方法等のDocker知識がないと厳しそうかなと感じました。 来年1月にはLTSバージョンが出るらしいので、その時にまた適宜修正したいと考えています。

ニフティアドベントカレンダー12月2日を務めさせていただきます、島田です。 プロフィールにも書いてありますが、新卒3年目の22歳で最近はコンテナランタイムについて勉強しています。 好きな寿司ネタはしめ鯖、最近楽しかったことはiPadでVMを起動させる遊びです。 アドベントカレンダーは初参加ですので、温かい目で見守って頂けると幸いです。 Docker Desktopが有料になるよ https://www.docker.com/pricing Docker Desktopが有料になる、という話は今やエンジニア以外でもご存知の方は多いのではないでしょうか。 いずれ有料化されると分かっていながらも発表された時は自分も驚きました。 今や開発は当然のようにコンテナで行われ、ニフティでも多くのコンテナがプロダクション環境で動作しています。 今回有料の対象となるのは従業員250名以上、または売上が1000万USD以上と、ほとんどの企業が有料対象となります。 今から脱Docker Desktopを行うのはリスクが高いため、pro以上のライセンスを購入することになると思うのですが、個人的にDocker以外のコンテナランタイムに興味が出たので勉強がてら色々いじってみてます。 以前社内LTにて、macの脱Docker Desktop手段としてlima-vmを紹介しました。 今回はPodmanを使ってみたので、やったことと思ったことを綴っていきたいと思います。 Podmanとは https://podman.io/ PodmanはDockerのように、runcなどの低レベルランタイムとやり取りをしてくれるCLIツールです。 開発はRedHatだそうで、OSSのプロジェクトとして公開されています。 Dockerと違いルートレスであるため、問題視されがちな特権ユーザを利用してホストOSに干渉する行為を防止でき、よりセキュアであるといえます。 使ってみる 早速使ってみます。環境は以下です。 host OS: windows10 VM: VMware Workstation 16 OS: debian11 まず、Podmanをインストールします。 aptでかんたんに入ります。 debian@debian:~$ sudo apt-get install podman debian@debian:~$ podman -v podman version 3.0.1 psするとコンテナ一覧が見られます。 Docker互換というだけあり、見た目がほとんど同じです。 debian@debian:~$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES テンションが上がってきたのでコンテナを動かしてみます。 debian@debian:~$ podman run --rm -itd busybox sh Error: error getting default registries to try: short-name "busybox" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf" なんか怒られました。 podmanのコンテナレジストリにはbusyboxというのはいない、と言ってるようです。 dockerのイメージを使うには次のように指定する必要がありました。 debian@debian:~$ podman pull docker.io/busybox Trying to pull docker.io/library/busybox:latest... Getting image source signatures Copying blob 3aab638df1a9 done Copying config d23834f29b done Writing manifest to image destination Storing signatures d23834f29b3875b6759be00a48013ba523c6a89fcbaeaa63607512118a9c4c19 debian@debian:~$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/busybox latest d23834f29b38 35 hours ago 1.46 MB 無事busyboxが取得できたので、起動してみます。 debian@debian:~$ podman run --rm -itd --name test docker.io/busybox sh 8113583a6c61ae37002321d74d5fcbda336c0e3d498612e640cf948bf514e1c1 debian@debian:~$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8113583a6c61 docker.io/busybox sh 6 seconds ago Up 6 seconds ago test 元気に動いています。 今回はbusyboxをそのままrunしていますが、podman buidや内部ネットワークの機能もちゃんともっているようです。 ついでに個人的にやろうと思っていたkata-fcをPodmanから使えるか試してみました。 debian@debian:~$ sudo podman run --rm -itd --name test-kata-fc --runtime=/opt/kata/bin/kata-runtime docker.io/busybox sh Error: OCI runtime error: Could not create cgroup for machine.slice:libpod:ccaaa04deb773de192ca4b89fff44f5ee8f0d505bc861b6c3c532c1cd1452571: cgroups: cgroup mountpoint does not exist だめみたいです。 Dockerでランタイムとして指定しても同じcgroupのエラーが出てしまっていたので、kata containersのインストールが悪いのかもしれません。 解決策がわかる方がいらっしゃったら是非教えて頂きたいです。 まとめ 今回はDockerの代わりにPodmanを使ってみました。 podというだけあってk8sのマニフェストからpodを作成することも出来るみたい(そっちがメインの機能？)で、結構便利そうです。 Dockerの移行先としても優秀で、何よりapt一発で入ってちゃんと動くところに感動しました。 企業としてPodmanに移行するのは流石にリスキーですが、個人で利用する分には全く問題なさそうです。 以上で島田の記事は終了です。 ニフティアドベントカレンダーはまだまだ続きますので、明日の投稿も是非ご覧ください！

なぜコンテナからコンテナを操作するのか？ 「コンテナからコンテナを操作したい！」なんて思ったことはないでしょうか？ 以下は私が開発したブラウザでプログラムを実行できるアプリのアーキテクチャ図です。いわゆる、Paiza.IOのようなものです。 あれ？コンテナ（Golang）からコンテナ（Python）に矢印が向いていますよね。これはコンテナ（Golang）で外部コマンドを叩き、公式のPython Imageからコンテナを起動しPythonファイルを実行してもらい結果を取得しています。 そんなことしなくてもEC2にDockerをインストールしてホストからDocker起動する方が良くね？って思うかもしれません。ですが筆者はどうしてもECSにまるっと任せたかったのです。その方がEC2に１からインストールしなくていいしデプロイも簡単だと思ったからです。（興味本位でDockerからDockerを起動したいと思ったのもある） コンテナからコンテナを操作する方法 DinD(Docker in Docker)とDooD(Docker outside of Docker)の２パターンがあります。詳しく見ていきましょう。 DinD(Docker in Docker) Dockerがインストールされているコンテナを使用しコンテナ内でホストとは別にDockerデーモンを動かす方法です。 現在起動中のコンテナを確認してください。（最低１つあると今回の検証が理解できます） $ docker ps dockerがインストールされているコンテナをバックグラウンドで実行します。 $ docker run --privileged --name dind -d docker:dind コンテナの中に入ります。 $ docker exec -it dind sh 起動中のコンテナを確認してください。何も表示されないはずです。 $ docker ps DinDではホストのDockerとは別のDockerが利用することができます。 DooD(Docker outside of Docker) コンテナ側からホストのdocker.sock (/var/run/docker.sock)をマウントすることでコンテナ上のDockerコマンドはホスト側のDocker環境で実行される。Dockerがインストールされているコンテナを使用するのはDinDと同じ 先程と同じように起動中のコンテナを確認します（最低１つあると今回の検証が理解できます） $ docker ps コンテナを起動して中に入ります。この時、ホストのdocker.sockをマウントする。 $ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker sh 起動中のコンテナを確認してください。ホストのコンテナ一覧が表示される。 $ docker ps このようにDooDではホスト側のDocker環境を共用することができる。 マルチステージングビルド じゃあコンテナ（Golang）にDockerをインストールしなければコンテナ（Python）を使用することができません。結論から言うと今回はマルチステージングビルドを用いました。 Dockerfile FROM golang:latest AS builder RUN mkdir /go/src/work WORKDIR /go/src/work COPY main.go . RUN CGO_ENABLED=0 GOOS=linux go build main.go FROM docker:latest COPY --from=builder /go/src/work/main ./ EXPOSE 10000 おまけ（コンテナ間マウント） このアプリを作成する上でコンテナ間マウントという技を使ったのでメモ代わりに --volumes-from ＜マウント元のコンテナ＞ とすることでコンテナ間マウントができる。サンプルは以下の通りです↓ $ docker run -it --volumes-from code python bash 参考文献

はじめに この記事では、「CA 1Day Youth Boot Camp バックエンド/インフラエンジニア編：現場で使うコンテナ技術、Kubernetes＆コンテナ入門(2021/11/24開催)」に参加したことで得られた知見をまとめます。この記事の対象者としては、 kubernetesについてサクッと知りたい Dockerは触ったことあるけど、k8sは無い といった方を想定しています。 私自身も、Dockerは触ったことがある(1ヶ月程度)がk8sは初心者(2日)の状態で上のインターンシップに参加したのですが、非常に勉強になりました。kubernetesに興味がある方の参考になれば幸いです。 Kubernetes(以下k8s)入門 定義 k8sとは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォーム（公式ドキュメントより） 要するに、コードベースで複数のDockerコンテナを適切に管理してくれるプラットフォーム。 Dockerとの関係 Docker それぞれのアプリケーションごとにコンテナを作成 k8s 複数のホストマシン間でデプロイされた複数のコンテナの管理 メリット 大量のコンテナの管理 コードで管理(Infrastructure as Code)するので設定が柔軟に行える。 デプロイの高速化 コンテナを元にデプロイを自動で行ってくれるので、手動でデプロイする必要がない。 高可用性 k8sはPodという最小単位で構成されているため、Podを増減させることで、可用性を高めることができる。 他にも様々なメリットがある。 k8sの概念 k8sを機能させるには、リソース（Kubernetes API オブジェクト）を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの desired state(望ましい状態)をyamlで記述する。desired stateをセットするには、Kubernetes APIを使用してリソースを作成する。通常はコマンドラインインターフェイス kubectlを用いてKubernetes APIを操作する。 概略図（一例） クラスタ k8sの様々なリソースを管理する集合体（上図の一番外側) コンポーネント：実行されるプロセス マスターコンポーネント：マスターノードで実行されるもの。クラスターに関する全体的な決定(スケジューリングなど)を行います kube-apiserverver etcd kube-scheduler kube-controller-manage ワーカーコンポーネント：すべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供する。 kube-proxy kubelet コンテナランタイム リソース クラスタ内の構成要素（上図のNode, Pod） リソース名 役割 Node クラスタで実行するコンテナを配置するためのサーバ Namaspace クラスタ内の仮想クラスタ Pod コンテナ実行に関する最小単位リソース RepricaSet 同じ仕様のPodを複数生成・管理する Deployment ReplicaSetの世代管理をする Service Podの集合にアクセスするための経路を定義 Ingress Serviceをk8sクラスタの外部に公開する ...（他にも多くのリソースがある） ... k8sでは、これらのリソースがクラスタ内で強調しながらコンテナシステムを構成している。以下では、各リソースにつてい詳しく見ていく。 準備 ここからは、実際に手を動かして確認していく。まずは、下準備。 準備1 Dockerをインストールしていない方 こちらからインストールする。 Dockerをインストールしている方 Docker for Desktopの設定で、k8sを有効にする 公式ドキュメントに従ってkubectlをインストールする。これを使用することで、k8sクラスターに対してコマンドを実行することができる。 $ docker version と $ kubectl version を実行し、それぞれバージョン情報が表示されればOK。 準備2（任意） サンプルファイルが入っているディレクトリのダウンロード $ git clone https://github.com/yagikota/Myk8s.git $ cd Myk8s を実行。 Myk8sディレクトリに入った状態で、進めていく。 準備3（任意） こちらに従って、Kubernetes Dashboardのインストール さらに、こちらにあるようにdashboard-adminuser.yamlをone-day-youth-bootcamp-ciuディレクトリに作成し、kubectl apply -f dashboard-adminuser.yamlを実行。 これで、Kubernetes Dashboardの使用準備が整った。 Node Nodeとはクラスタが持つリソースで最も大きい概念。 k8sのクラスタの管理下に登録されているDockerホストのこと。k8sでコンテナをデプロイするために利用される。クラスタはマスターノードとそれ以外で構成される。 Node一覧取得 $ kubectl get nodes NAME STATUS ROLES AGE VERSION docker-desktop Ready control-plane,master 3d3h v1.21.5 ローカル環境のk8sであれば、クラスタ作成時（k8sを有効にした時）に作られたVMがNodeの1つとして登録されているらしい。 Namespace Namespaceとは、k8sクラスタの内部の仮想的なクラスタ。 Namsespace一覧取得 $ kubectl get namespace NAME STATUS AGE default Active 3d23h kube-node-lease Active 3d23h kube-public Active 3d23h kube-system Active 3d23h kubernetes-dashboard Active 3d20h default: As its name implies, this is the namespace that is referenced by default for every Kubernetes command, and where every Kubernetes resource is located by default. Until new namespaces are created, the entire cluster resides in ‘default’. 参考文献 公式 参考資料 Pod Podとは、コンテナの集合体。少なくとも１つのコンテナを持つ。 Pod一覧取得 $ kubectl get pod No resources found in default namespace. Podを作成していないので、default namespaceにはPodが存在しない。 試しに、Podを作成する。 ファイルの説明（詳しくは、こちら） apiVersion: v1 # どのバージョンのKubernetesAPIを利用してリソースを作成するか kind: Pod # リソースの種類 metadata: # リソースを一意に特定するための情報 name: nginx # 文字列を指定 spec: # リソースの望ましい状態（specの正確なフォーマットは、リソースごとに異なる。cf. 参考文献 マニュフェストファイルの説明） containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 $ kubectl apply -f pod.yml $ kubectl get pod NAME READY STATUS RESTARTS AGE echo-pod 1/1 Running 0 20s 無事に作成できている。 k8s Dashboardで、default NamespaceのPodsを確認してみると、 となっている。 整理すると、 $ kubectl config current-context docker-desktop より、接続しているクラスタはdocker-desktopであるとわかる。そして、そのクラスタ内のNode一覧は、 $ kubectl get nodes NAME STATUS ROLES AGE VERSION docker-desktop Ready control-plane,master 3d3h v1.21.5 より、マスターノードだけ。 さらに、Namespace一覧は、 $ kubectl get namespace NAME STATUS AGE default Active 4d3h kube-node-lease Active 4d3h kube-public Active 4d3h kube-system Active 4d3h kubernetes-dashboard Active 4d であるとわかる。 今回、Podをapplyすると、１つしかないNode（マスターノード）にPodが作成され、k8sのアーキテクチャー概略図は、次のようになっていると考えられる。 ただし、Namespaceは省略した。 参考文献 公式 RepricaSet RepricaSetの目的は、どのような時でも安定したレプリカPodのセットを維持すること。指定された理想のレプリカ数にするためにPodの作成と削除を行うことにより、その目的を達成する。新しいPodを作成するとき、Podテンプレートを使用する。 RepricaSet一覧取得 $ kubectl get rs No resources found in default namespace. RepricaSetを作成していないので、default namespaceにはRepricaSetが存在しない。 試しに、RepricaSetを作成する。 $ kubectl apply -f rs.yml $ kubectl get rs NAME DESIRED CURRENT READY AGE frontend 3 3 3 12s $ kubectl get pod NAME READY STATUS RESTARTS AGE frontend-b9dqp 1/1 Running 0 27s frontend-h75sb 1/1 Running 0 27s frontend-lppc7 1/1 Running 0 27s 無事に作成できている。 ファイルの説明（詳しくは、こちら) apiVersion: apps/v1 kind: ReplicaSet metadata: # リソースを一意に特定するための情報 name: frontend labels: app: guestbook tier: frontend spec: # ReplicaSetの望ましい状態を定義 replicas: 3 # Podの数 selector: # .spec.template.metadata.labelsと一致させる。ReplicaSetが所有するPodを指定するため。（今回の場合、tier: frontendが一致している） matchLabels: tier: frontend matchExpressions: - {key: tier, operator: In, values: [frontend]} template: # template以下はPodの定義と同様に書く。templateの定義を持つPodの複製を行う。 metadata: labels: # spec.selectorと一致させる（2つのラベルのうちtier: frontendが一致している） app: guestbook tier: frontend spec: # Podの望ましい状態を定義 containers: - name: php-redis image: gcr.io/google_samples/gb-frontend:v3 resources: requests: cpu: 100m memory: 100Mi env: - name: GET_HOSTS_FROM value: dns # If your cluster config does not include a dns service, then to # instead access environment variables to find service host # info, comment out the 'value: dns' line above, and uncomment the # line below. # value: env ports: - containerPort: 80 参考文献 公式 youtube Deployment Deploymentは、ReplicaSetを管理・操作するためのリソース。実用上では、ReplicaSetを直接用いるのではなく、Deploymentのマニュフェストファイルを扱うことが多いらしい。 Deployment一覧取得 $ kubectl get deployments No resources found in default namespace. Deploymentを作成していないので、default namespaceにはDeploymentが存在しない。 試しに、Deploymentを作成する。 ファイルの説明（詳しくは、こちら） apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: # Deploymentの望ましい状態を定義 replicas: 3 # 3つのレプリカPodを作成 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 作成コマンド $ kubectl apply -f dep.yml $ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 4m48s $ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-66b6c48dd5 3 3 3 5m4s $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-66b6c48dd5-6jt7m 1/1 Running 0 5m46s nginx-deployment-66b6c48dd5-89frd 1/1 Running 0 5m46s nginx-deployment-66b6c48dd5-m98mj 1/1 Running 0 5m46s となり、宣言通りのリソースが作成されている。 参考文献 公式 Service Serviceとは、k8sクラスタ内で、Podの集合（主にReplicaSet）に対する経路やサービスディスカバリを提供するためのリソース。要は、k8sクラスタ内のネットワークをいい感じに捌いてくれるリソース。 Serviceには様々な種類がある。 ClusterIP(デフォルト) クラスター内部のIPでServiceを公開する。Serviceはクラスター内部からのみ疎通性がある。 NodePort 各NodeのIPにて、静的なポート(NodePort)上でServiceを公開する。そのNodePort のServiceが転送する先のClusterIP Serviceが自動的に作成される。<NodeIP>:<NodePort>にアクセスすることによってNodePort Serviceにアクセスできるようになる。 LoadBalancer クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開する。クラスター外部にあるロードバランサーが転送する先のNodePortとClusterIP Serviceは自動的に作成される。 ExternalName CNAMEレコードを返すことにより、externalNameフィールドに指定したコンテンツ(例: foo.bar.example.com)とServiceを紐づける。しかし、いかなる種類のプロキシーも設定されない。 ClusterIP まず、ClusterIPについて見ていく。 Serviceのマニュフェストファイル apiVersion: v1 kind: Service metadata: name: echoserver spec: ports: # The list of ports that are exposed by this service. - port: 80 # The port that will be exposed by this service. targetPort: 8080 # ターゲットとなるPodのポート番号 protocol: TCP # selector: app: echoserver #　このラベルと一致するPodがserviceのターゲットとなり、serviceを経由してtcpリクエストが流れる まず、 $ kubectl apply -f dep2.yml で、予めPodを作っておく。 $ kubectl get pod NAME READY STATUS RESTARTS AGE echoserver-8499b7dffc-24w99 1/1 Running 0 37m echoserver-8499b7dffc-7fn2h 1/1 Running 0 37m echoserver-8499b7dffc-9mfsr 1/1 Running 0 37m # Service をデプロイ $ kubectl apply -f servic.yml # 割り振られた IP を確認。 $ kubectl describe svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE echoserver ClusterIP 10.98.108.161 <none> 80/TCP 37m kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d23h ここで、ClusterIPは、クラスタ内部でのみ使用可能な仮想IPである。 サービスにアクセスするために、 クラスタ内に適当にPodを建ててsrviceの80番ポートにアクセスする（マニュフェストファイルで、.spec.ports.port=80としたため） $ kubectl run --image=centos:6 --restart=Never --rm -i testpo -- curl -s http://[svc-ip]:80 foo pod "testpo" deleted と表示されればOK。（ただし、[svc-ip] = 10.98.108.16, fooと表示される理由） ここで、ClusterIPはデプロイのたびに変わるので、その度にいちいち調べるのは面倒。そこで、こちらにあるように、DNS名を用いてアクセスしてみる。 $ kubectl run --image=centos:6 --restart=Never --rm -i testpo -- curl -s http://echoserver.default.svc.cluster.local:80 foo pod "testpo" deleted と表示されればOK。 整理すると、クラスタ内に適当に建てたPodから、http://[svc-ip]:80またはhttp://echoserver.default.svc.cluster.local:80でServiceにアクセスすると、マニュフェストファイル通り、app: echoserverのラベルを持つPodの8080ポートにリクエストが流れ、fooが表示される。 NodePort 次に、NodePortについて見ていく。 Serviceのマニュフェストファイル apiVersion: v1 kind: Service metadata: name: echoserver spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: NodePort # type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ExternalName, ClusterIP, NodePort, and LoadBalancer. selector: app: echoserver 先ほどと同様に、予めPodを作っておく。（作っていない場合） # Service をデプロイ $ kubectl apply -f svc_node_port.yml # 割り振られた IP を確認。 $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE echoserver NodePort 10.105.66.102 <none> 80:32694/TCP 32s kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 7d NodePortサービスを作成した場合、80:32694/TCPとあるように、ノードの32694ポートからServiceへアクセスできる。これにより、Serviceをk8sクラスタの外に公開できる。 実際、ローカル（クラスタ外）からService（クラスタ内）にアクセスできる。 $ curl http://localhost:32694 foo また、 適当に建てたPod(クラスタ内)からもService（クラスタ内）にアクセスできる。 $ kubectl run busybox -it --rm --image=busybox --restart=Never -- /bin/sh -c "wget -q -O- [NodeIP]:30937" foo ([NodeIP]=$ kubectl get node -owideコマンドで表示されるINTERNAL-IP) ともできる。 整理すると、クラスタ内外からServiceにアクセスすると、マニュフェストファイル通り、app: echoserverのラベルを持つPodの8080ポートにリクエストが流れ、fooが表示される。 Ingress Ingressは、クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するリソース。NodePortはL4層（トランズポート層）までしか扱えないが、IngressはL7層（アプリケーション層）まで制御できる。 公式にもあるように、ローカルk8s環境ではIngressを使用してServiceを公開することができない。 こちらに従って、nginx_ingress_controllerをデプロイしなければならない。 正直、Ingressについての理解が曖昧なので、ここでは参考文献を紹介するだけにする。 Ingressに関する参考文献 公式 nginx_ingress_controller kubernetesにingressを導入する方法 stackoverflow Empty ADDRESS kubernetes ingress Github Ingress Address EMPTY 参考文献 [挫折したエンジニア向け] Kubernetesの仕組みをちゃんと理解する⇦ざっくり理解できる リソースごとの公式ドキュメント Pod ReplicaSet Service Deployment Ingress マニュフェストファイルの詳細 ラベル(Labels)とセレクター(Selectors) Pod ReplicaSet Deployment Service Ingress インターンで用いた資料 Docker/Kubernetes実践コンテナ開発入門 （書籍）

触ってみたかったので導入して動作するところまでやってみます。 podmanってなに？ Podman(Pod Manager)とは、docker互換のコンテナエンジンです。コマンドがdockerと置き換わるだけでほぼ同じように利用することができます。 名前のとおりPodを管理するのでKubernetesのyamlなどもそのまま使える。 とはいえ、podmanはpodman、dockerはdocker、kubernetesはkubernetesというツールとしてみるのがよいかも。 今回はmacos上で利用できるようにしてみます。 準備 macはまだアップグレードしていないので、M1ではなくてIntelのBig Sur(11.6)になります。 $ brew install podman 同時にQEMUもインストールされています。 $ podman -v podman version 3.4.0 VMのダウンロード $ podman machine init Downloading VM image: fedora-coreos-34.20211004.2.0-qemu.x86_64.qcow2.xz Fedora CoreOSは、CoreOSが手掛けていたコンテナ向けOSをRed Hatが買収し、Fedoraと統合して登場したOSです。 cpu、メモリ等のサイズを変更するにはオプションを指定することもできます。 $ podman machine init --cpus 2 --memory 2048 --disk-size 30 podman起動 $ podman machine start podman起動確認 $ podman machine ls NAME VM TYPE CREATED LAST UP CPUS MEMORY DISK SIZE podman-machine-default* qemu 5 minutes ago Currently running 1 2.147GB 10.74GB VMなのでsshすることもできます。 $ podman machine ssh [core@localhost ~]$ 試す 簡単なコンテナを実行してみます。 $ podman run -it -p 8080:80 nginx:alpine chromeでhttp://localhost:8080にアクセス Welcome to nginx! ... 自動でポートフォワードされているのでそのままブラウザでアクセスできました。 もし以下のようなエラーが発生した場合、 Error: failed to parse "X-Registry-Auth" header for... ~/.docker/config.jsonの "auths" : { "https://index.docker.io/v1/" : { } を "auths" : { "index.docker.io/v1/" : { } と書き換えます。 $ podman run -it --rm hello-world Hello from Docker! ... 普通に動作できていますね。 コマンドをalias docker=podmanのようにして、もともとのdockerコマンドを置き換えても大丈夫のようです。 docker-composeを試す docker-composeは内部でdockerを使っているのでコマンドのエイリアスとDOCKER_HOSTを設定すればそのままいけそう。 podman-composeというツールがあるのですが、そちらは利用しません。 $ podman system connection list Name Identity URI podman-machine-default* /Users/develop/.ssh/podman-machine-default ssh://core@localhost:65228/run/user/1000/podman/podman.sock podman-machine-default-root /Users/develop/.ssh/podman-machine-default ssh://root@localhost:65228/run/podman/podman.sock # linuxなら $ export DOCKER_HOST=unix:/run/podman/podman.sock # macosなら $ export DOCKER_HOST=ssh://root@localhost:65228/run/podman/podman.sock sshの部分は.ssh/configに記述してexportしてもよさそう。 $vi .ssh/config Host podman HostName localhost Port 65228 User core IdentityFile /Users/develop/.ssh/podman-machine-default $ export DOCKER_HOST=ssh://podman pod機能を試す $ podman pod create -p 8080:80 --name sample-pod $ podman run -d --pod sample-pod -e POSTGRES_PASSWORD=mysecretpassword postgres $ podman run -d --pod sample-pod nginx $ podman pod ps POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS 1991381b0088 sample-pod Running 8 minutes ago 1c3c2bffa37c 3 $ podman ps --pod CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME 1c3c2bffa37c k8s.gcr.io/pause:3.5 9 minutes ago Up About a minute ago 0.0.0.0:8080->80/tcp 1991381b0088-infra 1991381b0088 sample-pod e370977bd0c0 docker.io/library/postgres:latest postgres About a minute ago Up About a minute ago 0.0.0.0:8080->80/tcp compassionate_leavitt 1991381b0088 sample-pod e4e48dba870e docker.io/library/nginx:alpine nginx -g daemon o... About a minute ago Up About a minute ago 0.0.0.0:8080->80/tcp lucid_jemison 1991381b0088 sample-pod # 構成をYAMLに出力 $ podman generate kube sample-pod > sample-pod.yaml # podの停止 $ podman pod stop sample-pod # podの起動 $ podman pod start sample-pod # podの削除 $ podman pod rm sample-pod # kubeのyamlから作成・起動 $ podman play kube sample-pod.yaml ひととおり動作できています。 最後に 手元のすべての開発環境を入れ替えるには少し時間がかかりそうな気がしています。 もともとdocker for macのvolume周りの問題があって代替となりそうな環境を探していたのですが、QEMUのVM上とVagrantでdockerするのもそれほど変わらないので、docker for macが重いよ〜という方は試してみてもいいかなと思います。 ちなみに導入難易度はVagrantにdockerを導入するほうが楽です。