ここまでのTPサービスは… バッチとかめっちゃがんばってCronとかにはまりつつも どーにかこーにかcronの対応も何とか出来て さて全体の動作確認をして開発環境＆本番環境つくってリリースまでいきまっしょい。 ってとこまで書いた気がするｗｗ 動作確認 ひとまず主要な画面での動作確認に留めて登録・更新・削除ができるかといった物までは 確認スピード感を優先してライトな感じでのテストのみを行った。 というわけで環境構築 テストも早々に終わらせ本番・開発環境構築 予算の都合上ConohaVPSでサーバー借りてそこに展開していくことに。 ちなみに環境は以下 OS:Debian メモリ：1GB CPU: 2Core ストレージ：100GB 早々に借りてまずはdocker関連のインストール 案外公式で事足りた。 docker-compose up が叩けるようになったらgitも使うのでgitもインストール git もインストールできたら一旦手動でリポジトリーをクローンしたりする。 この辺りの情報はネットにごろごろしているのでそちらをご覧になられたほうがよろしいよ。 ちなみにsshでクローンするようにしたら色々と都合よかったよ。 ついでに自動デプロイも構築 実際に職場でも上記のActionsを使ってやっていたので真似してみた。 職場のクオリティとは雲泥の差かもしれないけど、一応 git pullしてdockerを再起動まで 一気通貫で自動でできるようにはしてみた。自動化ってかっこいい＾＾ httpsで罠があって終わった件 さて、このサービスはセンシティブな情報を扱うサービスではないが 一応、一般的にhttps等使われているものは漏れなく合わせていきたいところ というわけでhttps-portalを使うことに ※先人の方の記事を参考に実施 ※しかし、この方法で実施した際にdockerの再起動の度にhttpsの再発行が走ってしまい リリース前にhttpsの証明発行ができなくなってしまう事態に…よく読んでなかったのが失敗だったわ。 リリースを優先したかったので一旦httpで行くことに。 そしてリリース！今後について とまぁ、httpsの発行等でつまずいたりしましたがまずはサービスの提供を優先 して、ひとまずはやり切った形で第１フェーズは終えられたんじゃないかなと思う。 そして今後は、ユーザー数の傾向を見ながら機能追加や性能改善にして行こうと思うが ふむ、このサービスをより発展させる方法について考えていこうと思う。 （機能追加やそのほかナレッジあったらまた記事化を予定） という訳でいったんおつかれちゃん～～＾＾

Linux ターミナル：ユーザーがコマンドを入力、実行結果を表示、あくまで画面担当 シェル：仲介役・命令解釈、Linuxに伝える Linux：受け取った命令を実行する echo "Hell" > tmp # ファイルに追加する cat tmp # 内容を表示 less tmp # 内容を全画面で表示・ファイルが長い時に使う 04 Dockerを使ってみよう イメージ：コンテナに必要なものを記載した雛形 ↓ 作成 コンテナ：OSの実行環境 ↓ 起動 実行 デーモンにタスクを伝える。 Dockerデーモンはバックグラウンドで起動しており、クライアントから受け取ったコマンド通りに、イメージやコンテナを作成・実行するアプリケーション。デーモンの流れは以下の通り。 DockerレジストリからDockerイメージを取得 イメージからコンテナを起動 コンテナを実行 05 Dockerを使ってみる ~/Docker 以下 main.rb #アプリケーションコード require "webrick" server = WEBrick::HTTPServer.new( DocumentRoot: './', BindAddredd: '0.0.0.0', Port: 8000 ) server.mount_proc('/') do |req, res| res.body = "hello" end server.start Dockerfile　こいつがDockerイメージを担う FROM ruby;2.7 RUN /var/www COPY main.rb /var/www CMD ["ruby", "/var/www/main.rb"] # イメージを作るコマンド、イメージをビルドする # -tオプション、タグ付け、.(今いるディレクトリ)に対して"sample/webrick:latest"というタグをつける。 # タグ名の構成 名前空間:ver情報 docker image build -t sample/webrick:latest . # 今存在しているイメージの存在 docker image ls # dockerのコマンド確認 docker --help # docker imageのコマンド確認 docker image --help # イメージの作成と起動 # -pオプション、ポート指定　ローカルポート:ドッカーポート（今回はこっちは8000番じゃなきゃいけない） # --name コンテナの名前をつけている。"付けたい名前 対象のイメージ" の順番 docker container run -p 8000:8000 --name webrick sample/webrick:latest # コンテナの停止 ctrlC docker container stop webrick # コンテナの起動状態の確認 docker container ls # 停止しているコンテナを含めた起動状態の確認 docker container ls -a # コンテナの削除 docker container rm webrick # "-d" バックグラウンドで実行 docker container run -d -p 8000:8000 --name webrick sample/webrick:latest # コンテナのログを確認する docker container logs webrick # コンテナ内で別のコマンドを実行したい # "コンテナ名 実行内容" docker container exec webrick ruby -v # 現在しようしていないイメージやコンテナを削除する。 docker system prune -a 06 Dockerfile ベースのイメージを指定して、ベースイメージに対してコマンドを羅列する。 FROM ruby:2.7 # ベースイメージを指定する WORKDIR /var/www # ワークディレクトリは、この後の作業をどこでやるか指定する。なかった場合は作成される。 COPY ./src /var/www # "./src"というソースコードをdockerのワークディレクトリにコピー CMD ["/bin/bash"] # 一度dockerコンテナ内に入る。bashはシェルの一種。 # イメージを作成 docker image build -t sample/sinatra:latest . # コンテナを作成・起動 # -itオプション、インティラクティブにコマンドを実行する。インティラクティブモード # -v ボリュームをマウント。ローカル修正 = コンテナも修正される # 最後にコンテナを作成するイメージ名を起動。 docker container run -it -p 4567:4567 --name sinatra -v ${PWD}/src:/var/www sample/sinatra:latest # sinatraをインストールしたい # "vendor/bundle"を作成、その下にライブラリを作成。 bundle config --local set path 'vendor/bundle' app.rbを./src内に作成 require 'sinatra' configure do set :bind, '0.0.0.0' # dockerコンテナ内にバインドしておくことで、ローカルからのどんな通信でも反応するように設定。 end get '/' do "Hello world!!" end # bundle execはgemファイルを使った処理を扱い際の枕詞 bundle exec ruby app.rb # -> webrickというwebサーバーを立ち上げる。 # 4567でサーバーへアクセス。 FROM ruby:2.7 WORKDIR /var/www COPY ./src /var/www RUN bundle config --local set path "vendor/bundle" RUN bundle install # RUN bundle config --local set path "vendor/bundle" \ # && bundle install # これは同義。 CMD ["bundle", "exec", "ruby", "app.rb"] docker image build docker container run -p 4567:4567 --name sinatra -v ${PWD}/src:/var/www sample/sinatra:latest 07 Docker Compose を用いたRails環境構築 # イメージのビルド docker-compose build # コンテナの作成・起動 docker-compose up -d # コンテナの停止・削除 docker-compose down # コンテナの一覧を表示 docker-compose ps # コンテナ操作のログを表示 docker-compose lgs # コンテナを作成してコマンドを実行 docker-compose run "サービス名" "コマンド" # 起動中のコンテナにコマンドを実行 docker-compose exec "サービス名" "コマンド" ./Dockerfile FROM ruby:2.7 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list && apt-get update -qq \ && apt-get install -y nodejs yarn # nodejsとyarnをapt-getでinstallしている。上では、nodejsとyarnをインストールするためのアップデート関連をしている。 WORKDIR /app # 作業ディレクトリを設定 COPY ./src /app # 作業ディレクトリへrubyアプリをコピー RUN bundle config --local set path 'vendor/bundle' \ # ライブラリのインストール先を指定 && bundle install # gemfileをインストール ./docker-compose.yml version: '3' services: db: # dbはmysql image: mysql:8.0 command: --default-authentication-plugin=mysql_native_password # mysqlの認証関連 volumes : - ./src/db/mysql_data:/var/lib/mysql # ローカルのボリュームをコンテナに同期 environment: MYSQL_ROOT_PASSWORD: password # 環境変数の設定 web: build: . # 今のディレクトリにあるDockerfileを参照する command: bundle exec rails s -p 3000 -b '0.0.0.0' # rails serverを起動。ポートはどこでもおっけい。 volumes : - ./src:/app # ソース共有 ports: - "3000:3000" # ローカルの3000ポートをdocker側の3000ポートに接続 depends_on: # 依存関係を示す - db # webはdbに依存している。IPアドレスを指定しなくても、繋いでくれる。 ./src/Gemfile source "https://rubygems.org" gem "rails", "~> 6.1.0" # dockerイメージを作成 docker-comopse run rails new . --force --databese=mysql # ファイルが変更された場合は、もう一度ビルドする docker-compose build config/database.yaml # docker-compose記載の内容に準じて、接続先情報を変更する。 default: &default adapter: mysql2 encoding: utf8mb4 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 ) %> username: root password: password host: db docker-compose run web rails db:create コンテナを起動 これらが終わった後に起動する。 docker-compose up 追加の操作 # コンテナを削除 docker-compose down dockerで本番環境 ./Dockerfile FROM ruby:2.7 ENV RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list && apt-get update -qq \ && apt-get install -y nodejs yarn # nodejsとyarnをapt-getでinstallしている。上では、nodejsとyarnをインストールするためのアップデート関連をしている。 WORKDIR /app # 作業ディレクトリを設定 COPY ./src /app # 作業ディレクトリへrubyアプリをコピー RUN bundle config --local set path 'vendor/bundle' \ # ライブラリのインストール先を指定 && bundle install # gemfileをインストール COPY start.sh /start.sh #コピー RUN chmod 744 /start.sh　#権限を付与 CMD ["sh", "/start.sh"]　#ファイルを実行 start.sh　一部の条件分岐を追加したい場合。 # !/bin/sh if [ "$(RAILS_ENV)" = "prodction" ] then bundle exec rails assets:precompile # 本番環境の設定 fi bundle exec rails s -p $(PORT:-3000] -b 0.0.0.

Ubuntu20.04のDocker上でFlaskを動作させる勉強をしていて、やっと何とか動作させることができたので、今後の参考のためにメモを残します。 flaskのpythonスクリプトの作成 まずはflaskのpythonスクリプトを作成します。 hello.py from flask import Flask app = Flask(__name__) @app.route('/') def hello(): return '''\ <html> <body> Hello </body> </html> ''' if __name__ == '__main__': app.run(host='0.0.0.0',port=8080) 元となるイメージファイルの検索とダウンロード Dockerの公式イメージの中で、pythonが入っているイメージを検索します。 コマンド docker search -f is-official=true python 出力結果 NAME DESCRIPTION STARS OFFICIAL AUTOMATED python Python is an interpreted, interactive, objec… 6263 [OK] django Django is a free web application framework, … 1081 [OK] pypy PyPy is a fast, compliant alternative implem… 279 [OK] hylang Hy is a Lisp dialect that translates express… 33 [OK] 4つほど出てきましたが、今回は1番上にあるNAMEがpythonのイメージを使うことにします。下のコマンドでpythonイメージをローカルにダウンロードします。 docker image pull python ダウンロードしたイメージの環境をbashで確認します。 docker container run --rm -it python bash Dockerfileの作成 下のDockerfileを作成します。 Dockerfile From python:latest COPY ./hello.py /hello.py RUN pip install flask CMD ["python","/hello.py"] Fromには元となるDockerイメージを記載します。（上で決めたpythonが書かれています。）バージョンも指定できますが今回は最新版latestにしています。 COPYはホストにある./hello.pyを、作成中のDockerイメージ内に/hello.pyとしてコピーを行います。 RUNはコマンドを実行します。作成中のDocker内でpip install flaskが実行されます。 CMDはビルドしてコンテナが実行された後、実行されるコマンドが書かれています。 イメージの作成 先に作成したhello.pyとDockerfileを同じフォルダに入れ、そのフォルダ内で下のコマンドを実行します。 コマンド docker image build ./ -t test --network=host -tオプションは作成するイメージの名前を決めるオプションで、今回はtestという名前にしてあります。 あと私の環境ではネットワークをhostにしないとリポジトリからflaskをダウンロードできませんでしたので--network=hostが書かれています。 ビルドの途中ではWARNING: Running pip as root will break packages and permissions.が出ますが、「rootでのインストール禁止」との警告らしいので（多分？）問題はありません。 イメージの確認 作成したイメージを確認します。 コマンド docker image ls 出力結果 REPOSITORY TAG IMAGE ID CREATED SIZE test latest 168ea0fde153 3 minutes ago 896MB python latest 5b3b4504ff1f 4 weeks ago 886MB 今回作成したイメージtestができていると思います。 イメージ（コンテナ）の起動 作成したイメージtestからコンテナを作成し起動します。（pythonで言うと、イメージはクラスで、コンテナはインスタンスみたいな感じです。） コマンド docker container run --rm --network=host test なお、Ubuntuの再起動後も自動的にコンテナを起動をさせたい場合には、下のコマンドにします。 コマンド docker container run --restart=always --network=host test おわりに プロキシがある場合にコンテナのネットワークが動作しなかったので苦労しました。（そのためプロキシを外して作成しました。） Docker/Ubuntuのネットワーク周りも、もっと詳しく勉強していきたいと思います。

コマンド編 カレントディレクトリにあるDockerfileからaというイメージを生成 $ docker build . -t a aというイメージからbというコンテナを作成してラン $ docker run -it -d --name bcd a 作ったbcdというコンテナの中に入る 個人的には.bash_profileやPATHをみる目的で使うことが多い $ docker exec -it bcd bash デバッグ編 find . -name "requirements.txt" ls -la | grep hoge 実際に作ったDockerfile Dockerfile... FROM --platform=linux/x86_64 ubuntu:20.04 WORKDIR /work SHELL ["/bin/bash", "-c"] RUN apt list --upgradable RUN apt update RUN apt install -y build-essential libffi-dev libssl-dev zlib1g-dev liblzma-dev libbz2-dev libreadline-dev libsqlite3-dev git wget RUN git clone https://github.com/yyuu/pyenv.git ~/.pyenv # pyenv ENV PYENV_ROOT /root/.pyenv ENV PATH $PYENV_ROOT/bin:$PATH ENV PATH $PYENV_ROOT/shims:${PATH} # Install Python and set default RUN pyenv install 3.7.4 RUN pyenv global 3.7.4 # Install pipenv RUN pip install pipenv RUN pipenv install \ flake8 \ jupyter \ jupyterlab \ kaggle \ matplotlib \ numpy \ pandas \ pep8 \ scikit-learn \ scipy \ seaborn \ signate \ sympy \ xgboost \ Pillow 備考 aptを使うのはよくないらしい。 今の認識だとbash_profileをビルド時に読み込めないっぽいのでENV命令を使う必要がありそう pyenvのglobal,localの挙動よくわからん pipfile,pipfile.lockを使えばもっと簡潔なディレクトリ構成になりそう 【pyvenv】 .pyvenv/versions/3.8.10/binの下にあるpipコマンドなどを使用している https://teratail.com/questions/25930から↓ - localを指定すると実行したディレクトリ内だけでPythonのバージョンが固定される - globalは、フォルダを超えてそのバージョンが使われる localはフォルダごとにバージョンを変えたい場合に使用できます。 globalは、すぐに起動して確認したい場合などで、標準で入っていてほしいバージョンを指定します。 アプリケーションであればlocalを指定しているほうが、外のバージョンが変わった際に悩まずに済みます。

はじめに DockerでLaravelの開発環境構築するか〜と思ってネット上をサーフィンしていたところ、2020年末にLaravelが公式にLaravel Sailというめちゃくちゃ便利なDocker環境をリリースしていたのでまとめました。 Dockerの知識がない方でも簡単に始められます。Laravel Sail初見の方はぜひ騙されたと思ってやってみてください！ 環境 macOS Big Sur Docker Desktop 3.3.3 Laravel Sailを使うためにはDocker Desktopのインストールが必要です。 新規Laravelアプリの作成とSailのインストール terminal $ curl -s https://laravel.build/<アプリ名> | bash アプリの作成とsailのインストールは同時に行われます。 これでmysql・redis・meilisearch・selenium・mailhogがデフォルトで利用できるようになりますが、withクエリを使って mysql pgsql mariadb redis memcached meilisearch selenium mailhog から使いたいサービスを個別指定することも可能です。 mysqlとredisを指定する例 $ curl -s "https://laravel.build/example-app?with=mysql,redis" | bash 既存のLaravelアプリにSailをインストールする場合 terminal $ composer require laravel/sail --dev $ php artisan sail:install アプリの起動 terminal $ cd <Laravelアプリ> $ ./vendor/bin/sail up -d http://localhost/にアクセスするとLaravelの初期画面が、http://localhost:8025にアクセスするとMailHogが表示されます。Sailをバックグラウンドで起動するにはデタッチの-dオプションを追加します。 エイリアス設定 呼び出し時に毎回./vendor/bin/sailと入力するのが面倒なので、エイリアスを設定します。こちらの記事を参考にさせて頂きました。 bashシェルの場合 $ alias sail='./vendor/bin/sail' $ source ~/.bash_profile zshシェルの場合 $ alias sail='./vendor/bin/sail' $ source ~/.zshrc コマンド実行 artisanコマンド $ sail artisan make:controller コントローラ名 phpコマンド $ sail php --version composerコマンド $ sail composer require ベンダー名/パッケージ名 nodeコマンド $ sail node --version npmコマンド $ sail npm run dev phpunitコマンド $ sail test 例：Vueのセットアップ コンテナ起動、停止以外は普段通りです。どれだけ普段通りか示すためにVueとの連携手順を載せておきます。 terminal laravel/uiのダウンロード $ sail composer require --dev laravel/ui #この時点でresources/js/components以下にvueコンポーネントが設置される vueの認証スカフォールドの生成 $ sail artisan ui vue --auth #認証機能をつけたい場合(ちなみにlaravelはjetstreamを推奨してます) パッケージのインストール $ sail npm install ビルド $ sail npm run dev #または sail npm run watchで自動コンパイル アプリ(コンテナ)の停止 terminal $ sail down #または'Ctr + C' おわりに いかがでしたか？Docker Desktopがあらかじめインストールされていた方は terminal $ curl -s https://laravel.build/<アプリ名> | bash $ ./vendor/bin/sail up の2行、時間にして約3秒くらいで開発環境構築が完了しましたね！(適当) 自分でDockerfile, docker-composeファイルを作る手間なくMySQL, mailサーバ等開発における必要最低限の機能が用意されるのでめちゃくちゃ便利です。 まだ試してない方はぜひ使ってみてください！ 参考

以前chocolateryでminikubeを入れていたのが原因っぽい。 PowerShellから以下コマンドを実行するとエラーが返ってくる。 > kubectl get pod Unable to connect to the server: dial tcp 127.0.0.1:62912: connectex: No connection could be made because the target machine actively refused it. 以下コマンドで設定を見てみると、minikubeがデフォルトになっていたので > kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE docker-desktop docker-desktop docker-desktop * minikube minikube minikube default 以下を実行して問題解決。 > kubectl config use-context docker-desktop Switched to context "docker-desktop". > kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * docker-desktop docker-desktop docker-desktop minikube minikube minikube default > kubectl get pod No resources found in default namespace.

既存のPJをdocker化の上、ECSとCodepipelineを使ってビルド、デプロイまで自動化しました。 その作業の備忘録として何個か記事に分けてまとめます。 全体の作業の概要 ゴールは下記二点 docker化したPJをCodepipelineを通じて本番にデプロイできること さらにそこにアクセスできること 大きく分けて下記のフローで行いました。 ローカルで既存PJをdockerビルドできるようにする dockerをインストール PJをクローン dockerファイルを作成 動作確認 そのPJをECS上で動かす ECRを作成してローカルで作ったイメージをプッシュ ECS作成 アクセス確認 CodePipelineを使ったデプロイ自動化構築 Codepipeline作成 ビルドプロジェクト作成 動作確認 Dockerとは 一応今回の主役みたいなものなので概要を紹介 正確な情報は公式ドキュメントまで 日本語版もあります。 Docker とは開発者やシステム管理者が、コンテナでアプリケーションを 構築（build）、実行（run）、共有（share）するためのプラットフォームです。 （日本語版ドキュメントより引用） 要するに、クソ面倒くさい環境構築を簡単に行うための仕組み。 これを実現するために、「コンテナ」と「イメージ」を使用する。 イメージ：ビルドしたソースコードをまとめたもの。 コンテナ：プロセスが走るサーバーのようなもの。この中にイメージを置いている。 で、これらを作るために下記のステップが必要。 dockerをインストール ソースコードを用意 dockerファイルを作成 それぞれの詳しいやり方はまた別の記事にまとめます。 メリットとデメリット あくまで所感ですが。 メリット 環境構築にかかる作業コストが限りなく少なくなる。 一度dockerファイルを作ってしまえば、あとはそれを誰かに渡すだけで環境構築が終了する。 基本的にローカルで動作するので、作業者が増えた時の個人環境の作成も簡単。 仮想マシン（VM）に比べ軽い デメリット だいぶ複雑なことをしてるため、理解と初めの構築に時間がかかる。 EC2とは違いsshアクセスなどは基本できないため、ログの収集などをするには専用の設定が必要 ローカルに限ってはログインコマンドがあるためこのデメリットはないが、普通のPJであればどこかのサーバー上にあげるので結局大変にはなる。 dockerを採用した経緯 とあるPJのOSが古くなってきたので、丸ごと置き換えることになったとこからスタート。 元々AWSで運用していたので、CodePipelineとかを挟めばデプロイまで自動化できる 更新頻度がそれなりに多いため、初期構築コストよりその後の運用面でのメリットがでかい。 単純にdockerに関するドキュメントや記事が多い。 ということでdocker化することになりました。 社内に経験者も多くいたので不明点を聞けるっていうのも大きかったです。 メジャーな技術はこういうのがいいですよね。 デプロイの仕組み ローカルから変更をプッシュすると、それが本番環境に自動反映される形で組みます。 下記大まかな流れ あらかじめECSにアクセスできるようにしておく 変更をプッシュするとCodePipelineが実行され、イメージがECRにプッシュされる。 ECRにプッシュされた最新版のイメージでビルドが実行される ビルド完了後、ECSで動いているコードが更新される これで反映完了 ECRとは AWSのサービスで、dockerイメージを置くリポジトリのようなもの。 ECSとは dockerコンテナを動かすための環境。 CodePipelineとは PJをビルド、リリースまでの挙動をカスタマイズできる

Flask+MySQL on docker勉強会 Webアプリケーションを作りシステム作りが初めてであってもどこからどこまで実施すれば動くシステムができるのかを開発して体験してみます。 FlaskはpythonのWebアプリ開発フレームワークです。Webサーバーを立ち上げてURLに応じた画面を表示したり、リクエストに対する処理をpythonで作り処理結果を返すことができます。 勉強会スケジュール 開発環境の構築(Python, docker, githubの使い方・フローの説明)​ 今回、勉強会で必要なツール等のインストールのサポートと簡単な開発の流れを説明します。 PythonでRest APIサーバープログラムの作成​ 何らかのデータモデルを参照・作成・変更・削除できるAPIを作ります。 各参加者に異なったデータモデルを割り当てるのでDBの設計、sqlの作成、そのモデルを扱うpythonプログラムの作成、apiの入出力の設計、リクエストを受け取って返却するプログラムの作成を行います。 Vue.jsでフロント画面の作成​ Vue.jsでWebフロントのサンプルプログラムを用意します。それに各自が作ったAPIを呼び出す、Vue.jsを使ったjavascriptプログラムを作成します。 本番環境の構築 AWS上にサービスを構築し、公開(リリース)します。 本番に構築する前に、開発環境に構築してプログラム、構築方法が正しいか確認します。 開発環境で問題ないことが確認できたら本番に構築します。また、本番構築後に再度構築が必要になった時、サービスを止めないで構築する方法などについても話をします。 事前準備 Flask+MySQL on dockerを始める準備を参考に環境を作ってください。 Project 今回の勉強会で作っていくシステムを次のリポジトリに公開しました。 次のコマンドを入力し、リポジトリよりcloneし、そのディレクトリに移動します。 $ git clone git@github.com:kaorunix/flask_sv.git $ cd flask_sv 次のコマンドでPipenvを起動します。 $ pipenv shell 次のコマンドで必要なパッケージをインストールします。 $ pipenv install --ignore-pipfile $ pipenv install --ignore-pipfile --dev プロジェクトは以下の様なディレクトリ構成となっています。 . ├── Pipfile ├── Pipfile.lock ├── Readme.md ├── backend │   ├── src │   │   ├── api.py │   │   ├── main.py │   │   ├── model │   │   │ ├── Account.py │   │   │ ├── Authentication.py │   │   │ ├── Authority.py │   │   │ ├── Status.py │   │   │ │ .... │   │   │ ├── __init__.py │   │   │ └── db.py │   │   └── restapi │   │   ├── __init__.py │   │   └── AccountApi.py │   └── tests │   ├── __init__.py │   ├── conftest.py │   └── model │   ├── __init__.py │   ├── test_Account.py │   ├── test_Status.py │   └── test_db.py └── tests └── __init__.py backend配下にアプリケーションサーバーのソースを入れてあります。 model配下にモデルを配置しています。 MVCモデルに準じてコード設計をしましょう。Model View Controller参照。 データベースのテーブル単位であったり、取り扱うデータ(例えば複数テーブルをJOINしたもの)単位にコードを書く事にします。 src直下のmain.pyの中にコントローラを実装します。 WEBアプリケーションFWであるflaskを使ってアプリケーションサーバーを実装します。 URL毎に異なった振る舞いをmain.pyを入り口に実装します。 アプリケーションは、次のコマンドで実行します。 $ pipenv run python src/main.py * Serving Flask app "main" (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: off * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit) 実行されると5000ポートでwebサービスが動く。 http://127.0.0.1:5000にブラウザでアクセスするとアプリケーションを実行することができます。 APIとしてaccountの取得をするAPIを用意しました。 http://127.0.0.1:5000/account/get/\ 上記URLへのアクセスに対して次のレスポンスが返ります。 { "body": { "name": "account", "id": <account_id>, "account_name": <account_name>, "start_on": "2021-01-01 10:00:00", "end_on": "2025-12-31 21:00:00" }, "status": { "code" : "I0001", "message" : "", "detail" : "" } } また、登録用のURL http://127.0.0.1:5000/account/create { "account_name": "start_on": "end_on": "opration_account_id": } のAPIに登録すると、作成日(created_at)、作成者(created_by)、更新日(updated_at)、更新者(updated_by)が更新される。 また、アカウントが作られた時はstatusに "1":"ACTIVE"が入る事にします。 statusは今後のことも考えて使用可能不可能を切り替えられる事にします。 "0":"NEW"　作成後有効化前の状態 "1":"ACTIVE"　有効状態 "2":"INACTIVE"　無効状態 "3":"DELETE"　削除状態 こういった決め事を考えることが設計です。 APIを正常に受け付けると次のレスポンスを返します。 { "body" : "", "status": "I0001", "message": "account {} was created.", "detail": "" } APIの設計を課題とします。後術再度確認します。 docker DBをdockerで作ります。 1. dockerインストール Windows に Docker Desktop をインストール 2. mysql dockerイメージからコンテナを作成 次のリポジトリに今回の開発で必要となるdocker-composeプロジェクトを作ってあります。 次のコマンドでgit cloneします。 $ git clone git@github.com:kaorunix/docker_mysql_flask_sv.git ディレクトリ docker_mysql_flask_sv/docker-mysql の配下に .env というファイルを作ります。 MYSQL_PASSWORD=password MYSQL_ROOT_PASSWORD=password passwordのところは自分の環境用のパスワードに変更しておきましょう。 このファイルをはgitに登録しないことでパスワードの漏洩を防ぐことができます。 docker-compose.yml ファイルには次の様に記載されています。 .env で設定した変数を埋め込むことができます。 docker-compose.yml # versionは3系が最新版で、versionによって書き方が異なる version: "3" services: mysql: build: ./mysql/ #Dockerfileからビルドすることを示す image: mysql:5.7 #original_mysql_world # イメージの名前 environment: MYSQL_DATABASE: flask_sv MYSQL_USER: creist MYSQL_PASSWORD: ${MYSQL_PASSWORD} MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} volumes: - ./mysql/db:/docker-entrypoint-initdb.d #初期データをマウントする場所 ports: - 3306:3306 Docker-docs-ja Compose ファイル内でのサービス定義などをみて書き方を調べてみてください。 docker-compose.yml があるディレクトリで次のコマンドを打つとmysqlのコンテナが起動されます。 $ docker-compose up -d docker psコマンドで実行中のコンテナを確認できます。 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 4a03b458af46 mysql:5.7 "docker-entrypoint.s…" 11 days ago Up 3 seconds 3306/tcp, 33060/tcp, 0.0.0.0:3316->3316/tcp docker-mysql_mysql_1 動いているのが確認できたらmysqlコマンドでログインできることを確認しましょう。 $ mysql -h 127.0.0.1 -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9 Server version: 8.0.23 MySQL Community Server - GPL Copyright (c) 2000, 2021, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> もし、うまくdockerが起動できなかったら次のコマンドでログを確認し、問題を解決します。 $ docker logs -f コンテナID docker-compose.ymlの次の行でPCのディレクトリをDockerコンテナの中にマウントしています。 docker-compose.yml volumes: - ./mysql/db:/docker-entrypoint-initdb.d #初期データをマウントする場所 docker_mysql_flask_sv/docker-mysql/mysql/db 配下が /docker-entrypoint-initdb.d にマウントされる事になります。 docker mysqlは /docker-entrypoint-initdb.d にsqlファイルを置いておくとコンテナを作成・起動時に実行してくれます。 こちらを参考にしました。docker mysql(Initializing a fresh instance) DB 現在、accountテーブルを用意してあります。 mysqlではデータベースという論理データベースを選択した後、目的のテーブルなどにアクセスできます。 show databases use <データベース名> show tables describe 論理データベースの一覧は show databases、テーブルの一覧は show tables、 テーブル構造を確認するのは describeコマンドで確認できます。これらのコマンドはmysql独自のコマンドです。他のデータベースはまた違うコマンドが用意されています。 mysql> show databases; +--------------------+ | Database | +--------------------+ | flask_sv | | information_schema | +--------------------+ 2 rows in set (0.12 sec) mysql> use flask_sv; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show tables; +--------------------+ | Tables_in_flask_sv | +--------------------+ | account | | authentication | | authority | +--------------------+ 3 rows in set (0.01 sec) mysql> mysqlから確認すると次の様に確認できます。 mysql> desc account; +--------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------+-------------+------+-----+---------+----------------+ | id | int | NO | PRI | NULL | auto_increment | | account_name | varchar(64) | NO | UNI | NULL | | | start_on | datetime | NO | | NULL | | | end_on | datetime | NO | | NULL | | | created_by | int | YES | | NULL | | | created_at | datetime | YES | | NULL | | | updated_by | int | YES | | NULL | | | updated_at | datetime | YES | | NULL | | | status | int | NO | | NULL | | +--------------+-------------+------+-----+---------+----------------+ 9 rows in set (0.08 sec) mysql> アカウントのテーブルを作るSQLは以下の様になります。 SQLはどのRDBでも基本同じです。ここで慣れておけばOracleや、PostgreSQL、SQLServerなどを使う時に役に立ちます。 DROP TABLE IF EXISTS `account`; CREATE TABLE `account` ( `id` int NOT NULL AUTO_INCREMENT, `account_name` varchar(64) NOT NULL UNIQUE, `start_on` datetime NOT NULL, `end_on` datetime NOT NULL, `created_by` int DEFAULT NULL, `created_at` datetime DEFAULT NULL, `updated_by` int DEFAULT NULL, `updated_at` datetime DEFAULT NULL, `status` int NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 課題として、先に説明したAPIの設計、テーブル定義の設計、テーブル作成を各メンバー一人ひとつづつ実施してください。 次回各、テーブルに対するapiを作っていきます。 題材は、Scrumのかんばんをイメージした「タスク管理システム」です。 業務等で発生する課題を記録、ステータスやスケジュール管理をしましょう。 開発とはお客さんが仕様を決めてくれるので言われるままに作れば良いと考えてしまいがちですが、システムがどの様に動くのか、どの様にしか動かないのかわかる人は開発者です。お客さんの目的を考えて何が必要か洗い出してください。 それぞれテーブルは１つでもできますが汎用性を考えて紐付けテーブルを作るのも検討してください。 プロジェクト 案件であったり取り扱うシステムであったりなどの大きな一括りにする。名称、説明の他、誰が作ったかいつ作ったかの情報も保持できる様にしましょう。 スプリント プロジェクト内での一定期間単位でタスクをまとめるものをスプリントと呼びます。1〜２週間でできるストーリーとタスクを紐付けます。期間情報、作成者情報、プロジェクトとの紐付けができる様にします。 プロジェクト、ストーリー、タスクと関連があります。 ストーリー 目標とする作業のまとまり。開発作業によって出来上がるもの例えば機能などを作る作業のくくりを保存します。例えば「商品一覧画面を作る」といったデータが入ります。 プロジェクト、スプリント、タスクと関連があります。 タスク プロダクトバックログを実現するためにやらなくてはならない作業単位の最も小さなもの。 タスク見出し、タスク内容、期限、工数、開始日、終了日、担当者が必須です。 プロジェクト、スプリント、ストーリー、アカウントと関連があります。 タスクのステータス タスクの処理ステータス。未着手、作業中、レビュー、完了を管理しましょう。 タスクと関連があります。 プロジェクトグループ プロジェクトに参加するアカウントをまとめて管理します。また、権限とも組み合わせて設定を容易にすることも念頭に置きましょう。 プロジェクト、アカウント、権限、業務、画面と関連があります。 権限 アカウントの権限を管理するテーブルを作ります。 権限によってアクセスできる業務・画面(データ)に制限をかけます。また操作できる内容も参照であったり更新 といった権限を紐付けできる様に考えてください。 プロジェクト、プロジェクトグループ、業務、画面、アカウントと関連があります。 業務 業務を権限によって利用制限をつけるための業務側のテーブル設計をしてください。 権限、アカウント、画面などと関連があります。 画面 現在はAPIを作っていますが、Web画面ができた時、その画面と権限を紐付けます。 権限、アカウント、業務などと関連があります。 APIを作る記事に続きます。

No. タイトル 1 Dockerで開発環境を構築する 2 ログイン認証を機能を実装する 3 記事投稿機能を実装する 4 AWS ECSを使ってデプロイする 5 Circle CIを使って自動テスト•デプロイをする はじめに Rails & Nuxtでポートフォリオを作成するシリーズの第4弾になります。 全5部構成でDocker,CircleCI,AWS等のモダンな技術を組み込んだ作品を完成させる予定です。 本章ではAWSのECSを利用してアプリのデプロイを行います。 以下、完成イメージ 事前学習 ↓AWSのネットワークの仕組みについて ↓ECSについて VPC作成 最初にリージョンを東京に切り替えておいて下さい。 name CIDRブロック sample-vpc 10.20.0.0/16 サブネット作成 後に作成するロードバランサーではサブネットが2つ必要な為、Nuxt,Rails,RDSでそれぞれ2つずつサブネットを用意します。 name CIDRブロック Region/AZ sample-front-subnet-1a 10.20.1.0/24 ap-northeast-1a sample-front-subnet-1c 10.20.2.0/24 ap-northeast-1c sample-back-subnet-1a 10.20.3.0/24 ap-northeast-1a sample-back-subnet-1c 10.20.4.0/24 ap-northeast-1c sample-rds-subnet-1a 10.20.5.0/24 ap-northeast-1a sample-rds-subnet-1c 10.20.6.0/24 ap-northeast-1c IGWの作成 VPC > インターネットゲートウェイより、sample-igwという名前でIGW作成。 その後、[アクション] > [VPCにアタッチ]でsample-vpcに関連づける。 ルートテーブルの作成 VPC > ルートテーブル > [ルートテーブルの作成]より作成画面に移ります。 name sample-front-route sample-back-route sample-rds-route IGW,サブネット,ルートテーブルの関連付け ルートテーブル > アクション > ルートを編集 > ルートを追加より、frontとbackのルートテーブルに対して、0.0.0.0に先ほど作ったIGWを関連付ける。 ルートテーブル > アクション > サブネットの関連付けを編集 より以下の表のように関連付け サブネット ルートテーブル sample-front-subnet-1a sample-front-route sample-front-subnet-1c sample-front-route sample-back-subnet-1a sample-back-route sample-back-subnet-1c sample-back-route sample-rds-subnet-1a sample-rds-route sample-rds-subnet-1c sample-rds-route セキュリティグループの作成 セキュリティグループ名 タイプ プロトコル ポート範囲 ソース sample-front-sg HTTP TCP 80 0.0.0.0/0 SSH TCP 22 My IPアドレス HTTPS TCP 443 0.0.0.0/0 カスタム TCP 3000 0.0.0.0/0 sample-back-sg カスタム TCP 8000 0.0.0.0/0 HTTPS TCP 443 0.0.0.0/0 sample-rds-sg MYSQL/Aurora TCP 3306 0.0.0.0/0 Route53 ドメインの取得 お名前.comより、ドメインの取得をします。Route53からでも取得可能ですが、値段が高いです。 あくまで練習用なので、適当に安いドメイン(.xyzとか)を取得すればOKです。 お名前.comでのドメイン取得方法については、以下を参照してください。 今回は下記を取得したという前提で進めていきます。 ドメイン名 役割 sample.com front sample-api.com back ホストゾーンの作成 Route53 > ホストゾーン > [ホストゾーンの作成] ホストゾーン詳細より、NSレコードの値/トラフィックのルーティング先をコピーして下さい。 お名前.comのネームサーバにNSレコードの値を登録 先ほどコピーしたNSレコードをお名前.comのDNSサーバーに登録します。 $: dig sample.com(取得したドメイン) +short NS 上記コマンドをターミナルから打ち、無事登録したNSレコードが表示されていれば反映されています。 ACMを使ってドメインに証明書を発行する sample.comとsample-api.comについて、それぞれSSL証明書を取得します。 ACM > 証明書のリクエスト > パブリック証明書のリクエストを選択。 ドメイン名 sample.com or sample-api.com 検証方法 DNS検証 タグ なし リクエスト後、検証画面に移るので、Route53でのレコード作成を押します。 そして、しばらくして(30分くらい)検証保留中から、発行済みステータスとなれば成功です。 RDSの作成 サブネットグループの作成 RDS > サブネットグループ > [DBサブネットグループを作成] RDSの作成にはサブネットグループが必要なので、先に作成しておきます。 サブネットはsample-rds-subnet1aとsample-rds-subnet1cを選択 グループ名はsample-subnet-groupとします。 RDSの作成・設定 設定 備考 作成方法 標準作成 エンジンのタイプ Maria バージョン 10.4.3 テンプレート 無料利用枠 DB インスタンス識別子 sample-rds マスターユーザー名 sample(任意) マスターパスワード samplepassword(任意) DB インスタンスクラス情報 db.t2.micro ストレージタイプ 汎用SSD ストレージ割り当て 20 VPC 先ほど作ったVPC(sample-vpc) サブネットグループ 先ほど作ったグループ(sample-subnet-group) 既存のVPCセキュリティグループ 先ほど作ったグループ(sample-rds-sg) アベイラビリティゾーン 指定なし 最初のデータベース名 app_production あとはデフォでOKです。 しばらくすると利用可能ステータスとなるので、そうしたらRDS作成完了です。 database.yml、credentials.yml.encの修正 ./back/config/database.yml production: <<: *default 　　　　database: app_production host: <%= Rails.application.credentials.rds[:host] %> username: <%= Rails.application.credentials.rds[:username] %> password: <%= Rails.application.credentials.rds[:password] %> これらの値は知られたくないので、credentials.yml内に環境変数として定義します。 $: docker-compose run -e EDITOR="vi" back rails credentials:edit ----------------------------------- rds: host: エンドポイント #RDS詳細画面のエンドポイントの欄の値 username: sample #設定したユーザーネーム password: samplepassword #設定したパスワード エンドポイントは↓の値をコピーしてください。 ロードバランサーの作成 EC2 > ロードバランサー > [ロードバランサーの作成]より作成画面へ移ります。 ロードバランサーの設定 front 種類の選択 Application Load Balancer ロードバランサーの設定 名前 sample-front スキーム インターネット向け IPアドレスタイプ ipv4 リスナー HTTP & HTTPS VPC sample-vpc アベイラビリティゾーン sample-subnet-front1a & 1c セキュリティ設定の構成 証明書タイプ ACM から証明書を選択する 証明書の名前 sample.com セキュリティポリシー デフォルト セキュリティグループ sample-front-sg ターゲットグループ 名前 sample-front-tg ターゲットの種類 インスタンス プロトコル HTTP ポート 8000 プロトコルバージョン HTTP 1.1 ヘルスチェック プロトコル HTTP パス / ターゲットの登録 スキップ back 種類の選択 Application Load Balancer ロードバランサーの設定 名前 sample-back スキーム インターネット向け IPアドレスタイプ ipv4 リスナー HTTP & HTTPS VPC sample-vpc アベイラビリティゾーン sample-subnet-back1a & 1c セキュリティ設定の構成 証明書タイプ ACM から証明書を選択する 証明書の名前 sample-api.com セキュリティポリシー デフォルト セキュリティグループ sample-back-sg ターゲットグループ 名前 sample-back-tg ターゲットの種類 インスタンス プロトコル HTTP ポート 3000 プロトコルバージョン HTTP 1.1 ヘルスチェック プロトコル HTTP パス / ターゲットの登録 スキップ ※ヘルスチェックのパスを"/"としていますが、ルートパスに何かしら200レスポンスを返すページを用意しておいて下さい。しないとエラーになります。 ターゲットはECSに登録した際に自動で追加されます。 Route53にAレコードを追加 Route53 > ホストゾーン > [レコードを作成] - レコードタイプ: A - 値: エイリアス - エンドポイント: Application Load Balancer - リージョン: 東京 - ロードバランサー: sample-front または sample-back sample.comとsample-api.com両方のドメインで行って下さい アプリを本番環境用に変更 AWSにデプロイするにあたり、本番環境用にいくつかファイルを変更します。 書き換えるのが面倒ならば、Dockerfile.dev,Dockerfile.proなど環境毎に分けて作成すると良いかもです。 back/Dockerfile FROM ruby:2.6.3-alpine3.10 ENV RUNTIME_PACKAGES="linux-headers libxml2-dev make gcc libc-dev nodejs tzdata mysql-dev mysql-client yarn" \ DEV_PACKAGES="build-base curl-dev" \ HOME="/app" \ LANG=C.UTF-8 \ TZ=Asia/Tokyo WORKDIR ${HOME} COPY Gemfile ${HOME}/Gemfile COPY Gemfile.lock ${HOME}/Gemfile.lock RUN apk update && \ apk upgrade && \ apk add --update --no-cache ${RUNTIME_PACKAGES} && \ apk add --update --virtual build-dependencies --no-cache ${DEV_PACKAGES} && \ bundle install -j4 && \ apk del build-dependencies && \ rm -rf /usr/local/bundle/cache/* \ /usr/local/share/.cache/* \ /var/cache/* \ /tmp/* \ /usr/lib/mysqld* \ /usr/bin/mysql* ADD . ${HOME} EXPOSE 8000 CMD ["bundle", "exec", "rails", "s", "-b", "0.0.0.0", "-p", "8000", "-e", "production"] front/Dockerfile FROM node:16.3.0-alpine ENV HOME="/app" \ LANG=C.UTF-8 \ TZ=Asia/Tokyo ENV HOST 0.0.0.0 WORKDIR ${HOME} RUN apk update && \ apk upgrade && \ npm install -g n && \ yarn install &&\ rm -rf /var/cache/apk/* ADD . ${HOME} EXPOSE 3000 RUN yarn run build CMD ["yarn", "start"] ./front/nuxt.config.js axios: { //baseURL: "http://localhost:3000", //ベストプラクティスとしてはURLを環境変数で設定した方が良いですが、今回は手直しします。 baseURL: "https://sample-api.com" }, ECRにリポジトリを作成・イメージのプッシュ ECRの作成・設定 ECR > [レポジトリの作成]よりレポジトリを作成します。 可視設定はプライベート、レポジトリ名はsample-front,sample-backとします。 作成後[プッシュコマンドの表示]を押すとコマンドが表示されるので、それに従いターミナルで実行します。尚、このコマンドを実行するにはAWS-CLIの事前インストールが必要なので、やっておきましょう。 実行後、ECRレポジトリ内にイメージが追加されたのを確認して下さい。 ECSの作成・設定 以下、個人的な用語整理 クラスター: ECSの適用範囲を決める タスク定義: docker-compose.yml タスク: docker-compose.ymlによって作成されたコンテナ群 サービス:クラスターとタスク定義を紐付ける ECSクラスターの作成 ECS > クラスター > [クラスターの作成]より作成画面に移ります。 クラスターテンプレート EC2 Linux + ネットワーキング クラスター名 sample-cluster プロビジョニングモデル オンデマンドインスタンス EC2 インスタンスタイプ t3.small インスタンス数 1 EC2 AMI ID* Amazon Linux2 ボリュームサイズ デフォ値 キーペア 任意 (無しにするとSSH接続でデバックできません) VPC sample-vpc サブネット sample-front-subnet1a & 1c パブリック IP の自動割り当て 適用 セキュリティグループ sample-front-sg コンテナインスタンスの IAM ロール デフォ値 タスク定義の作成 ECS > タスク定義 > [新しいタスク定義の作成]より作成画面に移ります。 front 設定 Value 起動タイプの互換性 EC2 タスク定義名 sample-front タスクロール ecsTaskExecutionRole ネットワークモード ホスト タスク実行ロール ecsTaskExecutionRole タスクメモリ (MiB) 700 タスク CPU (単位) 256 コンテナ名 sample-front イメージURL ECR sample-frontレポジトリのURI ポート 8000 back 設定 Value タスク定義名 sample-back タスクロール ecsTaskExecutionRole ネットワークモード ホスト タスク実行ロール ecsTaskExecutionRole タスクメモリ (MiB) 700 タスク CPU (単位) 256 コンテナの追加 コンテナ名 sample-back イメージURL ECR sample-backレポジトリのURI ポート 3000 サービスの作成 ECS > クラスター > sample-service >作成より作成画面に移ります。 front 設定 Value 起動タイプ EC2 タスク定義 sample-front サービス名 sample-front-service サービスタイプ REPLICA タスクの数 1 次のステップ ロードバランシングの種類 Application Load Balancer ヘルスチェックの猶予期間 30 サービス用の IAM ロールの選択 ecsServiceRole ロードバランサー名 sample-front ロードバランサーに追加 ターゲットグループ名 sample-front-tg Service Auto Scaling サービスの必要数を直接調整しない back 設定 備考 起動タイプ EC2 タスク定義 sample サービス名 sample-back-service サービスタイプ REPLICA タスクの数 1 次のステップ ロードバランシングの種類 Application Load Balancer ヘルスチェックの猶予期間 30 サービス用の IAM ロールの選択 ecsServiceRole ロードバランサー名 sample-back ロードバランサーに追加 ターゲットグループ名 sample-back-tg Service Auto Scaling サービスの必要数を直接調整しない 以上で完了です。最後に少しだけやることがあります。 コンテナ内に入ってdb:migrateする EC2インスタンスの中にssh接続し、その上でdockerコンテナ内に入り込みrails db:migrateします。 RDSを作成時に初期DBとして[app_production]を設定したため、db:createの必要ありません。 ssh -i {pemファイル} ec2-user@{インスタンスのpublicIP} EC2インスタンス内 docker ps で、現在起動しているコンテナが表示されます。 railsを起動しているコンテナのCONTAINER IDを指定して、以下コマンドを打つと、Dockerコンテナ内部に入れます。 EC2インスタンス内 docker exec -it {CONTAINER ID} sh ここで、環境を指定してdb:migrateします。 Dockerコンテナ内 rails db:migrate RAILS_ENV=production 起動確認 https://sample.comにアクセスすると、ホーム画面が表示されると思います！ うまくいかない場合... 記入ミス等、ケアレスミスしてないか見直す 英語の記事がないか調べてみる docker logs {コンテナid}でエラー原因を探る タスク詳細画面でエラー原因を見てみる などなど...

No. タイトル 1 Dockerで開発環境を構築する 2 ログイン認証を機能を実装する 3 記事投稿機能を実装する 4 AWS ECSを使ってデプロイする 5 Circle CIを使って自動テスト•デプロイをする はじめに ※初投稿なので多少読みづらいのはご容赦ください！ 本記事は私がエンジニアとして就活するにあたり、ポートフォリオを完成させるまでの過程を簡単にまとめたものです。解説書というよりは手順書という感覚で読んで頂ければと思います。 全5部構成でDocker,CircleCI,AWS等モダンな技術を組み込んだ作品を完成させる予定です。 本章ではDockerをローカル環境に導入して、開発環境を構築するフレーズまで進めていきます。 事前知識 Dockerって何やねんって方は以下の学習をおすすめします！ ↓ AWS公式の解説。前半部分でDockerの概念について分かりやすく解説されている。 ↓ Dockerの基礎をハンズオン形式で学べます。 Dockerのインストール Dockerの環境構築 まず最初に以下のディレクトリ&ファイルを作ってください。 Gemfile.lockの中身は空で大丈夫です。 sample |-docker-compose.yml |-front | |-Dockerfile | |-back |-Dockerfile |-Gemfile |-Gemfile.lock back/Dockerfile FROM ruby:2.6.3-alpine3.10 ENV RUNTIME_PACKAGES="linux-headers libxml2-dev make gcc libc-dev nodejs tzdata mysql-dev mysql-client yarn" \ DEV_PACKAGES="build-base curl-dev" \ HOME="/app" \ LANG=C.UTF-8 \ TZ=Asia/Tokyo WORKDIR ${HOME} COPY Gemfile ${HOME}/Gemfile COPY Gemfile.lock ${HOME}/Gemfile.lock RUN apk update && \ apk upgrade && \ apk add --update --no-cache ${RUNTIME_PACKAGES} && \ apk add --update --virtual build-dependencies --no-cache ${DEV_PACKAGES} && \ bundle install -j4 && \ apk del build-dependencies && \ rm -rf /usr/local/bundle/cache/* \ /usr/local/share/.cache/* \ /var/cache/* \ /tmp/* \ /usr/lib/mysqld* \ /usr/bin/mysql* front/Dockerfile FROM node:16.3.0-alpine ENV HOME="/app" \ LANG=C.UTF-8 \ TZ=Asia/Tokyo ENV HOST 0.0.0.0 WORKDIR ${HOME} RUN apk update && \ apk upgrade && \ yarn install &&\ rm -rf /var/cache/apk/* Gemfile source 'https://rubygems.org' gem 'rails', '6.1.3.2' docker-compose.yml version: "3" services: db: image: mariadb:10.4 environment: MYSQL_ROOT_PASSWORD: password MYSQL_DATABASE: touhou ports: - '3306:3306' restart: always volumes: - sample-db:/var/lib/mysql back: build: ./back command: /bin/sh -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0' " volumes: - ./back:/app:cached stdin_open: true tty: true depends_on: - db ports: - 3000:3000 front: build: ./front command: yarn run dev volumes: - ./front:/app:cached ports: - 8000:3000 volumes: sample-db: 作成し終わったら以下のコマンドを実行します。 #Dockerfileを基にコンテナを作成 [sample]$: docker-compose build #RailsAPIの作成 [sample]$: docker-compose run back rails new . -f -d mysql --api --skip-test #Nuxtアプリの作成 [sample]$: docker-compose run front npx create-nuxt-app@v3.6.0 front2 # 以下のような選択画面が出ます。 ? Project name --> Sample ? Programming language --> javascript ? Package manager --> Yarn ? UI framework --> bootstrap-vue ? Nuxt.js modules --> Axios ? Linting tools --> ESlint ? Testing framework --> None ? Rendering mode --> Universal ? Development tools --> None ? Github name --> 任意 ? Version control system --> Git Nuxtアプリを作成後、front2ディレクトリの中身を全てfrontディレクトリに移動させて下さい。そしたらfront2は削除してOKです。 データベースの設定 mariadbのコンテナを使用するよう書き換えます。 config/database.yml default: &default adapter: mysql2 encoding: utf8mb4 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: root password: password host: db development: <<: *default database: app_development test: <<: *default database: app_test production: <<: *default database: app_production $: docker-compose build $: docker-compose run back rails db:create $: docker-compose run back rails db:migrate 以上で構築完了です！ コンテナを立ち上げるとlocalhost:3000またはlocalhost:8000にアクセス出来るのが確認出来ると思います。 $: docker-compose up localhost:8000 localhost:3000 終わりに 以上で完了です、お疲れ様でした。 次回からポートフォリオの中身を作成していきます。良ければそちらもご覧ください！

経緯 お仕事でPleasanter作成お願いされる事が何回かあったんでdocker初心者だけどdocker-compose.yml作ってみたよ( ˘ω˘ ) 備忘録。 作ったもの pleasanterのベースは公式推奨のcentos7ベースと個人的な好みでdebianベースの２通り作ったよ( ˘ω˘ ) 前提環境 python3.6系以上 windowsも多分問題ないは。。。ず？(wsl2内のdockerでは動かず。無念。） 使い方 設定変更 ./.env DISTRIBUTION: pleasanterのベースイメージ。 (default) deb -> debian, cent -> centos7 TZ: timezone。よしなに。(default) Asia/Tokyo POSTGRES_PORT: postgres用のポート。(default) 5432 POSTGRES_PASSWORD: postgres用パスワード。変更不要。任意で。 POSTGRES_MEM: postgres割り当てメモリ。(default) 1G PLS_PORT: pleasanter用ポート。(default)8080 PLS_MEM: pleasanter割り当てメモリ(default) 1G スクリプト実行 python3 init.py ボリューム初期化、イメージのビルドしなおすか、コンテナ作成するか聞かれるので適当にyで流す。 やったこと。 参考にしたqiita: https://qiita.com/ta24toy27/items/986b3057e08f3da2fc06 上記から可能な部分のみDockerfile化。 パッケージのインストール回り プリザンターのソースzipをimage内で展開 ※pleasanterのソース更新は./pleasanter/pleasanter.zipを公式ダウンロードzipに差し替え、イメージリビルド想定。 pleasanterソースのRds.jsonの中身をコンテナの情報を(.envを元に)更新 pleasanter設定の反映。 pleasanterのサービスとnginxのサービスを起動。 心残り サービス起動の兼ね合いでprivileged: trueを外せない。 pleasanterのソースがzip展開

はじめに PCを変えるたびに開発環境やらtex環境やらを構築するのが面倒なので、当方はなるべくdockerイメージを使って環境構築するようにしています。 pythonを使うときは多くの場合にデータ分析やら機械学習を行うので、docker hubにあるpytorchイメージにjupyterlabやらscikit-learnやらを導入したイメージを使っていました。しかし、大変残念なことに、docker hubにあるpytorchイメージはlinux/amd64版のみが提供されており、linux/arm64（aarch64）なM1 mac民は使うことができません。 M1 macではまだnvidia GPUが使えないことから、心機一転してCPU実行のみをサポートする小さめのイメージを作成しました。 検証環境 Docker version 20.10.2, build 2291f61 running on Ubuntu 18.04.05 LTS x86_64 Docker version 20.10.7, build f0df350 running on macOS 10.15.7 x86_64 Docker version 20.10.7, build f0df350 running on macOS 11.4 aarch64 使い方 拙作のpytorch+jupyterlabをpullして実行してください。 latestタグのイメージを作っていないため、利用可能なタグを確認して実行してください。 CPUしか使わない人 本記事執筆時点ではpytorchはversion 1.9.0が最新です。ですので、以下のように実行します。 初回実行時に自動的にpullされると思います。 % docker run --rm -d -v $PWD:/app -p 8888:8888 \ pman0214/pytorch_jupyterlab:1.9.0 あとはブラウザでhttp://localhost:8888にアクセスすればjupyterlabが使えます。 jupyterlabのパスワードはjupyterとしてあります。 GPUも使う人 linux/amd64な環境でnvidia GPUを使う場合は、GPUサポートが付いているタグを指定して実行してください。 なお、GPUを使うためには--gpus=allなどのオプションを付ける必要があります。dockerもバージョン19.03以降である必要があると思います（未検証）。 % docker run --rm -d -v $PWD:/app -p 8888:8888 --gpus=all \ pman0214/pytorch_jupyterlab:1.9.0-cuda11.1-cudnn8-devel あとはブラウザでhttp://localhost:8888にアクセスすればjupyterlabが使えます。 jupyterlabのパスワードはjupyterです。 GPUにアクセスできているかどうかは、jupyterlab上で以下のようにpythonコードを実行すれば確認できます。 import torch print(torch.cuda.is_available()) TrueならGPUが使用可能で、GPU情報などを取得できます。 print(torch.cuda.get_device_name()) EPS画像出力への対応 論文などではいまだにEPS画像を提出せよなどという場合もあるため、EPS出力をサポートしたイメージも作りました。 使い方は上記のものと同じで、イメージ名だけが異なります。 ビルドしたい人向け ビルドに用いたファイル群はGitHubで公開しています。どうせならと思い、linux/amd64もlinux/arm64もサポートするmulti-architecture buildをしています。 なお、GPU対応版は別のベースイメージを使ってlinux/amd64用のみをビルドしました。 docker contextで接続先マシンを切り替えてbuildする手法もありますが（こっちのが速いらしい、当たり前か）、ここではより一般に適用可能なQEMUを使う場合で説明を行います。 ビルド用にQEMUを使ったコンテナが作成され、その中でビルドが実行されます。ビルドにはBuildkitが使われるので、ビルド用のコンテナなどを自分で準備する必要はありません。 ビルド方法の詳細はdockerの公式ドキュメントを参照するとよいです。概ね同じ手順になっていると思います。 準備（linuxでビルドする場合のみ） macやwindowsでビルドする場合は、最新版のDocker desktopが入っていれば準備は不要（になったはず）です。 experimental featureの有効化 まず、~/.docker/config.jsonに以下のような記述を追加するなどして、experimental featureを有効化します。 { ... "experimental": "true" ... } うまく有効化されれば、buildxコマンドが使えるようになります。 % docker buildx ls NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS default * docker default default running linux/amd64, linux/386 有効化できていない場合には、このようになります。確認していませんが、configを書いた後にdockerデーモンを再起動するなどが必要かもしれません。 % docker buildx ls docker: 'buildx' is not a docker command. See 'docker --help' QEMUの導入 ホストOSの機能で導入するとロクなことにならないので（経験者談）、dockerで配布されている導入キットを利用します。なお、このキットはBuildkitにも導入されています。 念のためインストールされている（かもしれない）QEMUを削除してから導入します。 % docker run --privileged --rm tonistiigi/binfmt --uninstall "qemu-*" % docker run --privileged --rm tonistiigi/binfmt --install all ビルダの準備 まず、buildxコマンドでビルダを準備します。名前は任意です。ここではmultiarchとしています。 --driverオプションでdocker-containerを指定することで、QEMUを実行するdocker-container上でビルドを行う指示をしています。 % docker buildx create --name multiarch --driver docker-container これで、buildx lsの出力はこのようになるはずです。 % docker buildx ls NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS multiarch docker-container multiarch0 unix:///var/run/docker.sock inactive default * docker default default running linux/amd64, linux/386, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/arm/v7, linux/arm/v6 *が付いているものが、使用されるビルダ（現在選択されているビルダ）です。 作成したビルダmultiarchを使用するように変更します。 % docker buildx use multiarch ビルダが切り替わっていることが確認できます。multi-architecture buildしないときはdocker buildx use defaultとしてdefaultに戻してください。 % docker buildx ls NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS multiarch * docker-container multiarch0 unix:///var/run/docker.sock inactive default docker default default running linux/amd64, linux/386, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/arm/v7, linux/arm/v6 ビルダのコンテナを作成します（実はこれをやらなくても、自動で作成されるという噂も・・・）。 % docker buildx inspect --bootstrap ビルド アーキテクチャを指定して、buildxコマンドを使ってビルドします。 注意するのは、--loadを付ける点です。付けないと、ビルドした結果は破棄されます（という警告も表示されます）。 --loadの代わりに--pushとすればdocker hubにpushされます。この場合にはあらかじめdocker loginしておき、-tオプションで適切なタグを指定しておいてください。 % git clone https://github.com/pman0214/docker_pytorch-jupyterlab.git % cd docker_pytorch-jupyterlab % docker buildx build \ --platform linux/amd64,linux/arm64 \ -t "pytorch_jupyterlab_latex:1.9.0" \ --build-arg VER=1.9.0 . \ --load 複数のアーキテクチャのビルドは並行して実行されます。 なお、QEMUを用いてビルドするのでホストと異なるアーキテクチャ上でのビルドは特に遅いです。例えば、Core i9 3.6GHz 16core with 64GB memoryなUbuntu 18.04マシンで、上記ビルドには全部で2時間ほど要しました。 GPU版のビルド GPU版はamd64なマシンがあれば、multi-architecture buildをする必要はありません。 Dockerfileが異なるので、その指定だけ忘れずにビルドしてください。 % docker build \ -f Dockerfile_cuda \ -t "pytorch_jupyterlab_latex:1.9.0-cuda11.1-cudnn8-devel" \ . おわりに 本記事では、pytorch + jupyterlabなdockerイメージの使い方及び作り方を説明しました。これでM1 macな人たちもdockerさえ入っていればaarch64ネイティブで実行されるpytorchライフを送れますね。 ビルドをgithub action化するとさらに幸せになれそうですが、未着手です。