はじめに 最近Railsの開発環境を作成しています。 こちらの記事で構築手順を載せています。 そこで、GitにリポジトリをあげたコードをCloneして起動したところうまく起動できない事態が発生したため手直しのさいに解決した方法をまとめます。 問題 WebpackerとRailsのDocker環境を作成して、起動したところ以下のようなエラーが発生します。 Webpackerのログをみたところコンパイルはされていそうでした。 webpacker_1 | js/main-aa1872663912a6956e52.js.map 756 KiB main [emitted] [dev] main webpacker_1 | manifest.json 654 bytes [emitted] webpacker_1 | ℹ ｢wdm｣: Compiled successfully. ネットでも調べましたが、自分の欲しい答えに行きつかず自力で解決しましたので紹介します。 解決方法 実はこのエラー2回遭遇しました。 1回目 タイプミス <%= javascript_pack_tag 'application' %> # ここでエラー <%= stylesheet_pack_tag 'application' %> エラーの場所がこのように特定されているので、インポート対象のファイルを確認したところ javascripts/packs/application.js import Rails from "@rails/ujs" import Turbolinks from "turbolinks" import * as ActiveStorage from "@rails/activestorage" import "channels" import "bootstrap" import '../javascripts/application.js' # applicationがapplocationになっていた import '../stylesheets/applocation.scss' Rails.start() Turbolinks.start() ActiveStorage.start() applicationがapplocationにタイプミスしておりました。 2回目 manifest.json問題 これが今回特定するのにかなり検証してつきとめた問題になります。 Webpackerではコンパイルをした際に/public/packs/manifest.jsonに情報の記録を行います。 このmanifest.jsonはWebpackerコンテナとRailsコンテナどちらにもある必要があります。 manifest.jsonを作成するのはcommand: webpack-dev-serverで起動しているwebpackerコンテナなのでRailsコンテナにはボリュームを共有する必要がありました。 初回起動はGit cloneしてきているのでpublic/packs/manifest.json自体はignoreされておりディレクトリにはありません。その状態で起動するとWebpackerコンテナのみにファイルがある状態になりエラーの原因となります。2回目以降の起動はローカルにできた/public/packs/manifest.jsonがマウントされて動くというメカニズムになっていました。 そこで、RailsとWebpackerコンテナ間で/publicを共有することで対応します。 docker-compose.yml version: "3.9" services: rails: build: . container_name: rails command: bundle exec puma -C config/puma.rb volumes: - .:/myapp - public-data:/myapp/public # 追加 - tmp-data:/myapp/tmp - log-data:/myapp/log - /myapp/node_modules env_file: - .env depends_on: - db environment: WEBPACKER_DEV_SERVER_HOST: webpacker webpacker: build: . volumes: - .:/myapp - /myapp/node_modules - public-data:/myapp/public # 追加 command: ./bin/webpack-dev-server environment: WEBPACKER_DEV_SERVER_HOST: 0.0.0.0 ports: - "3035:3035" user: root db: image: mysql:8.0.27 container_name: db environment: TZ: Asia/Tokyo MYSQL_ROOT_PASSWORD: ${DB_PASSWORD} ports: - "3306:3306" volumes: - db:/var/lib/mysql web: build: context: containers/nginx volumes: - public-data:/myapp/public - tmp-data:/myapp/tmp ports: - 80:80 depends_on: - rails volumes: db: driver: local bundle: driver: local public-data: # 追加 tmp-data: log-data: 注意としてはpublic/packs/manifest.jsonが生成されて共有されるまで少し時間がかかるので、エラーがでてしまうかもしれないというところです。なんどかリロードすれば読み込まれるかと思います。 おわりに gitからクローンして手を加えないといけない環境になってしまったのでなんとか解決したくかなりの検証を行ってここまでたどり着きました。ネットにも記事がありませんでしたので誰かの助けになればと思います。 このような検証をすると深い理解ができるようになります

はじめに 最近Railsの開発環境を作成しています。 こちらの記事で構築手順を載せています。 そこで、GitにリポジトリをあげたコードをCloneして起動したところうまく起動できない事態が発生したため手直しのさいに解決した方法をまとめます。また、この記事とは別にWebpackerの問題がもう一つ起きています。 以下の記事から確認ください。 問題 DockerでWebpackerを環境を作成して起動したところ以下のエラーが発生しました。 webpacker_1 | error Command "webpack-dev-server" not found. 何度か起動するとエラーが消えて、git cloneしてくると初回は発生しました。 解決方法 これはyarn installされた際に自動生成される/node_modulesがないためにおこるエラーです。 本来であればWebpackerコンテナの中にyarn installされた時点で/node_modules/webpack-dev-serverが作成されます。しかし、Git clone時はローカルにnode_modulesが存在しないため(gitignoreされているため)ファイルマウントがおきずにこのようなエラーになります。 そこで、Dockerfile内でyarn installをすることでエラーを解決しました。 FROM ruby:alpine3.13 ARG UID RUN adduser -D app -u ${UID:-1000} && \ apk update \ && apk add --no-cache gcc make libc-dev g++ mariadb-dev tzdata nodejs~=14 yarn WORKDIR /myapp COPY Gemfile . COPY Gemfile.lock . RUN bundle install COPY --chown=app:app . /myapp RUN yarn install # 追加 COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] # EXPOSE 3000 # CMD ["bundle", "exec", "rails", "server", "-b", "0.0.0.0"] USER app RUN mkdir -p tmp/sockets RUN mkdir -p tmp/pids そして、このコンテナ内で作成されたnode_modulesを使えばよいのですが、docker-compose.ymlでボリュームを設定していないとコンテナ内のnode_modulesは勝手に削除されます。 【Docker】docker compose upするとnode_modulesがマウントされて消える問題 こちらの記事通りにdocker-compose.ymlでvolumesマウントして消えないようにします。 またRailsコンテナでもnode_modulesは必要なので(yarn installしたライブラリを利用するので)、こちらにもvolumeを追加します。 docker-compose.yml version: "3.3" services: rails: build: . container_name: rails command: bundle exec puma -C config/puma.rb volumes: - .:/myapp - public-data:/myapp/public - tmp-data:/myapp/tmp - log-data:/myapp/log - /myapp/node_modules # 追加 env_file: - .env depends_on: - db environment: WEBPACKER_DEV_SERVER_HOST: webpacker webpacker: build: . volumes: - .:/myapp - /myapp/node_modules # 追加 command: ./bin/webpack-dev-server environment: WEBPACKER_DEV_SERVER_HOST: 0.0.0.0 ports: - "3035:3035" おわりに yarnやpackage.jsonについて初めて勉強したのでかなり沼りました。 また、ネットにもほしい情報はなく検証をかなりして解決することができました。 このあとにWebapackのCSSやVueが読み込まれなかったり、Template Errorが発生するトラブルを解決していますので困った方は確認してみてください。 参考 【Docker】docker compose upするとnode_modulesがマウントされて消える問題

概要 ABCIでdocker imageを使う際，実は公式に説明があるdockerhub以外のrepositoryからもimageをpullすることができると同僚に聞いたが，そのやり方がまとめられたページが見つからなかったのでメモを残す． この記事が前提とする人 Singularityが何かしっている． ABCIも知っている． Docker ImageがSingularity Imageに変換できることは知っている （参考) dockerhubが何かを知っている． gitlabのプロジェクトにdocker imageをpushできるらしいと知っている． 困り毎 ABCIの公式ドキュメントではdockerhub上にあるpublicなdocker imageをsingularityのimageに変換する(pullする)方法が説明されている．しかし，同僚によると任意のdocker repositoryのimageをpullできるらしい． しかし，公式ドキュメントにあるコマンドでは特に指定なくdockerhubにつないでいるように見える．つなぐ先のdocker repositoryを指定する方法がよくわからない． 例えばgitlab上のdocker imageを使いたい場合，接続先をdockerhubからregistry.gitlab.com/<<path/to/your/docker_image>>変更する必要がある．(<>はdocker imageが格納されているプロジェクトのパス）． 結論 ABCI上でpullをする前に singularity remote login でrepositoryにログインすれば良い． 具体的には下記のようなコマンドを実行する必要がある． % module load singularitypro % singularity remote login --username <<gitlabのユーザ名>> docker://registry.gitlab.com % singularity pull <destination>.sif docker://registry.gitlab.com/<<path/to/your/docker_image>> ここで <> はABCIのディレクトリ内に作られる.sifイメージの任意の名前である． <参考: Singularityの公式ドキュメント> この作業をする上で上記以外でハマったところ 今回，そもそもgitlabのrepositoryにdocker imageをpushするのが初めてだった． これを使用としたのだが， gitlab repository にdocker loginする際にエラーがでて困った． エラーメッセージをよく読んだところ，作成してあったgitlab tokenでは api の項目が無効になっていたためにloginできないようだった．このため，gitlab tokenを「api」の項目にチェックをつけて再度作成した（ついでに全部チェックしてしまったが，誰かにtokenを渡すわけではないのでまぁ良いか...）．

背景 Dockerコンテナ環境でZabbix Serverを構築していますのでメモ書きしてみました。 動作環境 ホスト側 OS:Ubuntu Server 20.04.3LTS Docker CE version 20.10.12 docker compose version v2.2.3 コンテナ側 公式のDockerコンテナを使用します。 GitHub - zabbix/zabbix-docker: Official Zabbix Dockerfiles ベースには以下のLinuxディストリビューションが用意されています。 Alpine CentOS Oracle Linux Ubuntu 今回は例によって軽量のAlpine Linux版を使用します。 なおCentOS 8はOracle Linux 8に置き換わった様子です。 zabbix's Profile | Docker Hub Docker環境の準備 以下のページにて紹介していますので参考にしてみて下さい。 Linuxサーバー環境のDockerインストールメモ - Qiita Zabbix 5.0構築の方針 Zabbixには状況に応じて複数のサービスがあります。 Zabbix Agent Zabbix Server Zabbix Web interface(Apache2 or Nginx) Zabbix Proxy Zabbix Java Gateway Zabbix SNMPtraps またデータベースも以下が利用出来ます。 MySQL PostgreSQL SQLite3 今回は通常のZabbix Serverを構築する事として以下の必要なサービスを選択します。 Zabbix Agent Zabbix Server Zabbix Web interface(Nginx) MySQL Zabbix 5.0のシステム構築 公式ドキュメントを参考にdocker composeでシステム全体を作成します。 Zabbix Documentation 5.0 5 Installation from containers gitリポジトリの取得 GitHubからZabbix公式のgitリポジトリを取得します。 $ git clone https://github.com/zabbix/zabbix-docker.git $ cd zabbix-docker gitブランチの変更 標準のブランチは最新版の5.4になりますが状況に応じてLTSの5.0に変更します。 ここでは安定長期サポートLTSの5.0に変更します。 $ git branch * 5.4 $ git checkout 5.0 $ git branch * 5.0 5.4 $ git branch --set-upstream-to=5.0 $ git pull docker-compose設定 サンプルの「docker-compose.yaml」ファイルが複数用意されているので適当にコピーします。 今回はAlpine-MySQL版を選択します。 $ cp docker-compose_v3_alpine_mysql_latest.yaml docker-compose.yaml リソースオプションの警告 docker compose起動時にswarmのリソースオプションのエラーがでます。 「WARNING: The following deploy sub-keys are not supported and have been ignored: resources.reservations.cpus」 該当項目(reservations:)を複数箇所コメントアウトします。 docker-compose.yaml # reservations: # cpus: '0.5' # memory: 512M Zabbix Agent Zabbix-Agentのコンテナは「docker-compose.yaml」ファイル設定のprofilesでオプション扱いなので外して有効化します。 これでホスト側が監視出来ます。 docker-compose.yaml zabbix-agent: image: zabbix/zabbix-agent:alpine-5.0-latest #profiles: # - full # - all PHPのタイムゾーン設定 env_vars/.env_web PHP_TZ=Asia/Tokyo docker composeの起動 $ docker compose up -d 問題がなければ以下のように起動しています。 $ docker compose ps NAME COMMAND SERVICE STATUS PORTS zabbix-docker-db_data_mysql-1 "sh" db_data_mysql exited (0) zabbix-docker-mysql-server-1 "docker-entrypoint.s…" mysql-server running zabbix-docker-zabbix-agent-1 "/sbin/tini -- /usr/…" zabbix-agent running zabbix-docker-zabbix-server-1 "/sbin/tini -- /usr/…" zabbix-server running 0.0.0.0:10051->10051/tcp zabbix-docker-zabbix-web-nginx-mysql-1 "docker-entrypoint.sh" zabbix-web-nginx-mysql running (starting) 0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp 一つ停止しているコンテナ「zabbix-docker-db_data_mysql-1」はMySQLのデータ格納コンテナを作成するプロセスです。このままで問題ありません。 初回起動時はデータベースが空なので順次基本データを取得して作成されます。 その為ログイン画面が正常に表示されるまではしばらく時間がかかります。 お茶でも飲みながらしばらく休憩して待ちましょう。 グラフの日本語の文字化け Web設定でユーザー言語を「日本語(ja_JP)」を選択しても、グラフ表示のキャプションが豆腐文字で文字化けするので修正します。 以下のページで紹介しているので参考にしてください。 DockerでAlpine LinuxのZabbix 5.0グラフが豆腐になる日本語表示を修正するメモ - Qiita

Ubuntu20.04 + gpu docker環境を構築したので流れをメモしておきます。最後がポイントです。 環境 Ubuntu 20.04 (サーバーインストール) NVIDIA GPU 手順 GPUドライバーインストール 昔はいろいろやった気がしたのですが、レポジトリーを追加して一気にいけます。 sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt install ubuntu-drivers-common sudo ubuntu-drivers autoinstall 動作確認は再起動後nvidia-smiで確認。ずらずら出てきます。 CUIログイン サーバー用としてインストールしてもインストールするとするとGUI環境のログインが表示されてしまうので、CUIにしたい場合はログイン方法を変更します。 # 確認 $ sudo systemctl get-default graphical.target # 設定変更 $ sudo systemctl set-default multi-user.target # 確認 $ sudo systemctl get-default multi-user.target Dockerインストール 通常の手順通りでインストールします。 sudo無しでdockerが動作するように変更 $ sudo usermod -aG docker $USER 動作確認 # normal docker docker run hello-world GPU環境動作確認 docker run —gpus all nvidia/cuda:10.0-cudnn7-devel-ubuntu18.04 nvidia-smi nvidia-smiの画面が出ずに失敗します。dockerでGPUが使えるようになっていないようです。 docker: Error response from daemon: could not select device driver “” with capabilities: [[gpu]]の解消方法 curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | \ sudo apt-key add - distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-container-runtime/$distribution/nvidia-container-runtime.list | \ sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt-get install nvidia-container-runtime service docker restartで再起動 再度dockerのGPU動作を確認します。 docker run —gpus all nvidia/cuda:10.0-cudnn7-devel-ubuntu18.04 nvidia-smi OK!! 参考： ごにょごにょ ハード側の問題もあり結局数回インストールしなおす羽目になったので、メモしてありました。また気が向いたらクリーンインストールするかもしれないので、メモを公開しておきます。

概要 超絶簡単なDockerファイルを作成したがビルド時にエラーが出たので問題箇所をまとめる やったこと 下記のDockerファイルを作成した ファイル名: DockerFile 内容 FROM centos:7 RUN yum update -y 当該のファイルが有るディレクトリで下記コマンドを実行してDockerファイルのビルドを試みた。 $ docker build . 下記の様なエラーが出た。 failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount103727647/Dockerfile: no such file or directory 原因 Dockerファイルの名前が間違えていた。 誤: DockerFile 正: Dockerfile ファイル名を修正してビルドを行ったところ正常にコンテナが立ち上がった。 ビルド後に$ docker imagesで確認したところちゃんとイメージが作成されていた。 REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> 4178759679c0 About a minute ago 493MB

概要 Dockerの用語の理解が若干進んできたので忘れないようにまとめておく ご注意 一部理解に誤りがある可能性があります。 用語まとめ そもそもDockerって？ コンテナ技術のコンテナを管理するツールだよ Dockerの他にもLinux ContainersとかHyper-Vコンテナとかいろいろあるよ コンテナって？ ものを運ぶコンテナのイメージそのままだよ Linux上につくられるよ じゃあなんで自分のMacの上にコンテナつくれるの？ Dockerが裏でLinuxを起動させてくれているよ Linux起動しているってなんか重そう そんなに重くないよ、コンテナ建てるためだけの機能しか入ってないLinuxを建ててくれているからね アプリケーションを動作させるのに必要なものが原則一個づつ入っているよ 例えばlaravelの開発環境を作りたいなら下記のコンテナが必要だよ PHPのコンテナ DBのコンテナ Webサーバーのコンテナ コンテナの中と外は隔たりがあるよ PHPとかDBとかWebサーバーがそれぞれ隔たれた場所にあるとそれぞれの通信がだるそうだよね、でも大丈夫だよ 後から説明するdocker composeが全部解決してくれるから気にしなくていいよ Dockerイメージを元に作成するよ（$ docker runコマンドを実行するとDockerイメージからコンテナを作成するよ） Dockerイメージって？ コンテナの設計図だよ DockerHubから取得するか、Dockerファイルから作るよ（$ docker buildコマンドを実行するとDockerファイルからDockerコンテナを作成するよ） DockerHubって？ 公式もしくは有志の人が作ってくれたDockerイメージが配布されている場所だよ ファミレスのドリンクバーみたいな感じだよ（ジュースがDockerイメージ） Dockerのユーザー登録をしておくと無制限にDockerイメージを取得することができるよ、おすすめだよ Dockerファイルって？ Dockerイメージをコード化したものだよ DockerHubに自分がほしいイメージがなかった時はDockerファイルを自分で書く必要があるよ じゃあ結局メリットってなんなの？ Dockerファイルやバージョンを指定して公式のDockerイメージを使えば誰でも同じ開発環境構築ができるよ そもそもDockerファイルを使えば開発環境構築をコードで管理できるよ 人の手があまり入らず開発環境構築ができるから楽だし間違いがないよ、すぐ開発に移れるね、やったね コンテナ間の通信ってどうやるの？ コンテナのIPとポートを指定すればばできるよ、でもIP指定はちょっとだるいよね docker composeを使って簡単に行うことができるよ コンテナが増えてきて管理がだるいんだけど それもdocker composeを使えば楽になるよ docker compose コンテナをまとめて管理できるものだよ docker compose用の設計図を書いておけば一つのコマンドでまとめて関連するDockerコンテナを起動することができるよ ちょっとだけ書き方は違うけど$ docker buildとか$ docker runとかの命令を記載するよ ここまで理解できれば「Dockerなんとなく分かります！」って言っていいのかもね

目次 AWS Cloud service provider の追加 ロールの作成とパーミッションの設定 VPC ネットワークリソースの作成 起動テンプレートの作成 インスタンスの起動 この記事は 前回の記事クラウドオーケストレーターのはじめかたではクラウドオーケストレーターのインストールと Kubernetes のセットアップまで説明しましたが、ここではクラウドオーケストレーターをマルチクラウドのポータルとして Amazon EC2 を管理するためのセットアップ方法を紹介します。 IAM ロールの作成 前提条件として、このドキュメントを参考に IAM ロール を作成してください。AWS 上もしくはオンプレでのクラウドオーケストレーターの運用形態によって、以下のようにクレデンシャルの準備が必要です。 クラウドオーケストレーターAWS （EC2 や EKS、ECS）上で動作させる場合、 IAM ロールをクラウドオーケストレーターのインスタンスにアタッチしてください。 オンプレミス環境で動作させる場合、IAM パーミッションの権限を含んだ AWS Access Key ID と AWS Secret Access Key が必要です。 AWS Cloud service provider の追加 管理者権限（Administrator role）のユーザーでサイトにログインします。 Tour または Cloud service provider のメニューより Add AWS Cloud service provider を選択します。 以下の画面より AWS Cloud を選択します。 Name と Account ID を入力、Regions を選択します。 AWS のクレデンシャルを指定します。方法として ３つのオプションがあります。 オプション 利点 A IAM ロール アクセスキーID と シークレットアクセスキーを設定する必要がない。※IAM ロール は Instance Profile ともいいます。クラウドオーケストレーターでは Instance Profile と表記しています。 B アクセスキー アクセスキーID と シークレットアクセスキーを使用して特定のアカウントの AWS リソースにアクセスできる。 C Assume ロール クラウドモジュールが他の IAM ロールを Assumeし、そのロールで AWS リソースにアクセスできる。 D スイッチロール クラウドモジュールが他の IAM ロールを別のアカウントにスイッチし、切り替え先のロールで AWS リソースにアクセスできる。 A. IAM ロールを使用する方法 - Credentials のセクションより Use Instance Profile にチェックを入れます。 B. アクセスキーを使用する方法 - Use Instance Profile のチェックを外した状態で、Access Key ID と Secret Access Key を入力します。 C. Assume ロールを使用する方法 - Assume Role セクションの Use Assume Role をチェックし、IAM Role 名を入力します。 D. スイッチロールを使用する方法 - 上記 C. に加え、Use Switch Role をチェックし、スイッチ先の Account ID と IAM Role 名を入力します。 フォームを保存し、作成に成功すると以下のメッセージが表示されます。 ロールの作成とパーミッションの設定 Manage メニューから People → Roles に移動し Add Role ボタンをクリックします。 Role の名前を入力しロールを作成します。 作成したロールのドロップダウンから Edit Permission を選択します。 作成したロールに許可したい権限にチェックを入れ、画面最下にある Save ボタンをクリックします。 VPC ネットワークリソースの作成 AWS Cloud service provider の作成後に、Cloud service provider メニューから AWS を選択すると以下の画面が表示されます。 以下の順番で各々の VPC 内のネットワークリソースを作成します。 手順 ステップ 1 SSH キーペアの作成 2 VPC の作成 3 Subnet の作成 4 Internet Gateway の作成 5 Internet Gateway を VPC にアタッチ 6 AMI イメージのインポート 7 Security Groupの設定 SSH キーペアの作成 Key Pairs のタブより Add AWS Cloud key pair をクリックします。 フォームに必要事項を入力し保存するとキーペアが作成されます。 作成に成功するとリストに作成したキーペアが追加されています。 ※キーペアと同様の手順で VPC、Subnet、Internet Gateway の順番でリソースを追加します。Internet Gateway について、以下の手順で VPC に Internet Gateway をアタッチする必要があります。 Internet Gateway を VPC にアタッチ Internet gateway リストの中の Operations Links のドロップダウンから Attach を選択します。 Attach する VPC を選択し、Attach ボタンをクリック。 Attach に成功するとThe Internet Gateway is attached to VPCのメッセージと共に、Operation linksにDetachが表示されます。 AMI イメージのインポート Images タブより Import AWS Cloud image を選択します。 フォームに必要事項を入力し Import をクリックします。 インポートが成功すると表にインポートしたイメージが表示されます。 セキュリティグループの設定 Security groups タブより Add AWS Cloud security group を選択します。 フォームに必要事項を入力し Save ボタンをクリックします。 作成に成功すると表に作成したセキュリティグループをが表示されます。 リストより作成した セキュリティグループをを選択し、Edit タブから Inbound rule と Outbound rule の IP protocol と CIDR IP を設定し保存します。 起動テンプレートの作成 Design → Launch template に移動し、Add launch template を選択します。 フォームに必要事項を入力の上、Workflow の Status を Review に設定し保存します。 インスタンスの起動 リストより作成した起動テンプレートをクリックし、Approve を選択します。 Approve に成功したら、Launch タプを選択します。※ Approve へのステータス変更は管理者権限のあるユーザーが行います。 Automatically terminate instance にチェックを入れ、画面最下にある Launch ボタンをクリックします。 起動に成功すると、The launch template has been launched のメッセージと共に、インスタンスのリストに起動したインスタンスが表示され、ステータスが Pending として表示されます。 以上でクラウドオーケストレーターを使って EC2 インスタンスを起動することができました。 終わりに クラウドオーケストレーターをもっと深く知りたい方のために、関連サイトをリストアップしておきます。 ※この記事は @TamakiFujino が作成し、@dcm_naoi が加筆・修正いたしました。 クラウドオーケストレーターのはじめかた（元記事） クラウドオーケストレーターのホームページ クラウドオーケストレーターの YouTube チャンネル クラウドオーケストレーターのドキュメント（英語） クラウドオーケストレーターの開発サイト クラウドオーケストレーターのソースコード

目次 AWS Cloud service provider の追加 ロールの作成とパーミッションの設定 VPC ネットワークリソースの作成 起動テンプレートの作成 インスタンスの起動 この記事は 元記事クラウドオーケストレーターのはじめかたではクラウドオーケストレーターのインストールと Kubernetes のセットアップまで説明しましたが、ここではクラウドオーケストレーターをマルチクラウドのポータルとして Amazon EC2 を管理するためのセットアップ方法を紹介します。 IAM ロールの作成 前提条件として、このドキュメントを参考に IAM ロール を作成してください。AWS 上もしくはオンプレでのクラウドオーケストレーターの運用形態によって、以下のようにクレデンシャルの準備が必要です。 クラウドオーケストレーターAWS （EC2 や EKS、ECS）上で動作させる場合、 IAM ロールをクラウドオーケストレーターのインスタンスにアタッチしてください。 オンプレミス環境で動作させる場合、IAM パーミッションの権限を持つアクセスキー IDとシークレットアクセスキーが必要です。 AWS Cloud service provider の追加 管理者権限（Administrator role）のユーザーでサイトにログインします。 Tour または Cloud service provider のメニューより Add AWS Cloud service provider を選択します。 以下の画面より AWS Cloud を選択します。 Name と Account ID を入力、Regions を選択します。 AWS のクレデンシャルを指定します。方法として、以下の 4つのオプションがあります。 オプション 利点 IAM ロール アクセスキーID と シークレットアクセスキーを設定する必要がない。※IAM ロール は Instance Profile ともいいます。クラウドオーケストレーターでは Instance Profile と表記しています。 アクセスキー アクセスキーID と シークレットアクセスキーを使用して特定のアカウントの AWS リソースにアクセスできる。 Assume ロール クラウドモジュールが他の IAM ロールを Assumeし、そのロールで AWS リソースにアクセスできる。 スイッチロール クラウドモジュールが他の IAM ロールを別のアカウントにスイッチし、切り替え先のロールで AWS リソースにアクセスできる。 IAM ロールを使用する方法 Credentials のセクションより Use Instance Profile にチェックを入れます。 アクセスキーを使用する方法 Use Instance Profile のチェックを外した状態で、Access Key ID と Secret Access Key を入力します。 Assume ロールを使用する方法 Assume Role セクションの Use Assume Role をチェックし、IAM Role 名を入力します。 スイッチロールを使用する方法 上記 C. Assume ロールを使用する方法に加え、Use Switch Role をチェックし、スイッチ先の Account ID と IAM Role 名を入力します。 最後にフォームを保存し、AWS Cloud service provider の作成に成功すると以下のメッセージが表示されます。 ロールの作成とパーミッションの設定 Manage メニューから People → Roles に移動し Add Role ボタンをクリックします。 Role の名前を入力しロールを作成します。 作成したロールのドロップダウンから Edit Permission を選択します。 作成したロールに許可したい権限にチェックを入れ、画面最下にある Save ボタンをクリックします。 VPC ネットワークリソースの作成 AWS Cloud service provider の作成後に、Cloud service provider メニューから AWS を選択すると以下の画面が表示されます。 以下の順番で各々の VPC 内のネットワークリソースを作成します。 手順 ステップ 1 SSH キーペアの作成 2 VPC の作成 3 Subnet の作成 4 Internet Gateway の作成 5 Internet Gateway を VPC にアタッチ 6 AMI イメージのインポート 7 Security Groupの設定 SSH キーペアの作成 Key Pairs のタブより Add AWS Cloud key pair をクリックします。 フォームに必要事項を入力し保存するとキーペアが作成されます。 作成に成功するとリストに作成したキーペアが追加されています。 ※キーペアと同様の手順で VPC、Subnet、Internet Gateway の順番でリソースを追加します。Internet Gateway について、以下の手順で VPC に Internet Gateway をアタッチする必要があります。 Internet Gateway を VPC にアタッチ Internet gateway リストの中の Operations Links のドロップダウンから Attach を選択します。 Attach する VPC を選択し、Attach ボタンをクリック。 Attach に成功するとThe Internet Gateway is attached to VPCのメッセージと共に、Operation linksにDetachが表示されます。 AMI イメージのインポート Images タブより Import AWS Cloud image を選択します。 フォームに必要事項を入力し Import をクリックします。 インポートが成功すると表にインポートしたイメージが表示されます。 セキュリティグループの設定 Security groups タブより Add AWS Cloud security group を選択します。 フォームに必要事項を入力し Save ボタンをクリックします。 作成に成功すると表に作成したセキュリティグループをが表示されます。 リストより作成した セキュリティグループをを選択し、Edit タブから Inbound rule と Outbound rule の IP protocol と CIDR IP を設定し保存します。 起動テンプレートの作成 Design → Launch template に移動し、Add launch template を選択します。 フォームに必要事項を入力の上、Workflow の Status を Review に設定し保存します。 インスタンスの起動 リストより作成した起動テンプレートをクリックし、Approve を選択します。 Approve に成功したら、Launch タプを選択します。※ Approve へのステータス変更は管理者権限のあるユーザーが行います。 Automatically terminate instance にチェックを入れ、画面最下にある Launch ボタンをクリックします。 起動に成功すると、The launch template has been launched のメッセージと共に、インスタンスのリストに起動したインスタンスが表示され、ステータスが Pending として表示されます。 以上でクラウドオーケストレーターを使って EC2 インスタンスを起動することができました。 終わりに クラウドオーケストレーターをもっと深く知りたい方のために、関連サイトをリストアップしておきます。 クラウドオーケストレーターのはじめかた（元記事） クラウドオーケストレーターのホームページ クラウドオーケストレーターの YouTube チャンネル クラウドオーケストレーターのドキュメント（英語） クラウドオーケストレーターの開発サイト クラウドオーケストレーターのソースコード

Docker Desktop for Mac and Windows有償化に伴い、cliで現開発環境が稼働できるように、M1 Macで実施したので備忘録がてら残す。 ※MySQL5.7対応でかなりハマったのは内緒の話。 構成 lima + dockerを使用した形を採用。 ホストマシンの上にLima（Virtual Machine）を立ち上げて、その中のDocker Engineを使用する構成。 手順 Docker Install brew install docker ※ Docker fot Desktop経由でインストール済みの場合はどうにかしてアンインストールすること。 lima Install brew install lima docker-compose install 執筆当時（20220119）はhomebrew経由でのinstallはできないようなので、物理ファイルを落とす。 # https://github.com/docker/compose/releases/ wget https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-$(uname -s)-$(uname -m) sudo mv docker-compose-$(uname -s)-$(uname -m) /usr/bin/docker-compose sudo chmod +x /usr/bin/docker-compose lima setting # 任意のPathでOK mkdir -p ~/local/lima vim ~/local/lima/develop-docker.yml develop-docker.yml cpus: 4 memory: "8GiB" disk: "100GiB" images: - location: "https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64.img" arch: "x86_64" - location: "https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-arm64.img" arch: "aarch64" mounts: # プロジェクトを追加 - location: "~/git" writable: true containerd: system: false user: false provision: - mode: system script: | #!/bin/sh sed -i 's/host.lima.internal.*/host.lima.internal host.docker.internal/' /etc/hosts - mode: system script: | #!/bin/bash set -eux -o pipefail command -v docker >/dev/null 2>&1 && exit 0 export DEBIAN_FRONTEND=noninteractive curl -fsSL https://get.docker.com | sh # NOTE: you may remove the lines below, if you prefer to use rootful docker, not rootless systemctl disable --now docker apt-get install -y uidmap dbus-user-session - mode: user script: | #!/bin/bash set -eux -o pipefail systemctl --user start dbus dockerd-rootless-setuptool.sh install docker context use rootless probes: - script: | #!/bin/bash set -eux -o pipefail if ! timeout 30s bash -c "until command -v docker >/dev/null 2>&1; do sleep 3; done"; then echo >&2 "docker is not installed yet" exit 1 fi if ! timeout 30s bash -c "until pgrep rootlesskit; do sleep 3; done"; then echo >&2 "rootlesskit (used by rootless docker) is not running" exit 1 fi hint: See "/var/log/cloud-init-output.log". in the guest portForwards: - guestSocket: "/run/user/{{.UID}}/docker.sock" hostSocket: "{{.Dir}}/sock/docker.sock" message: | Success. limactl start ~/local/lima/develop-docker.yml > 脳死 Enter echo 'export DOCKER_HOST=$(limactl list develop-docker --format unix://{{.Dir}}/sock/docker.sock)' >> .bash_profile # 疎通確認(正常に実行できればOK) docker --version docker-compose --version