AWSへのrails on Dockerアプリのデプロイは、何をもって完了となる？

Question

PF作成中の初学者です。
サイトの方が一通り完成し、それまでサイト公開に使っていたherokuからawsに切り替えるべくデプロイ方法を模索しています。

githubからクローンして、docker-compose up -dするとブラウザでも手持ちのスマホでもサイトにアクセスできる（http://〇〇〇.〇〇〇.〇〇←この末尾に:80やら:3000やら打たなくてもアクセスできる）ので、本番環境で公開はできているのかな？と思うのですが、docker-compose stopするとアクセスできなくなります。

この状況にかなり違和感があり、デプロイできているのかいないのかがよくわからないです。
圧倒的知識不足で恐縮なのですが、以下に書く私の認識が合っているかどうかお聞きしたいです。
・dockerコンテナごとec2サーバーに移してデプロイする今回のような場合、コンテナが常時起動していることをもってデプロイ完了となる。
・今回の問題は、ec2起動時にdockerコンテナを自動起動するような設定がなされていないために起こっている。
・もしコンテナを自動起動する設定ができれば、あとはawsのサイトからec2インスタンスを再起動しさえすれば常時サイトにアクセス可能となる。

---

「ec2起動時にdockerコンテナを自動起動するような設定」というのは、
無料！かつ最短？で Ruby on Rails on Docker on AWS のアプリを公開するぞ。
こちらのサイトの2-5、「Docker環境を整える」で紹介されている

[[e-mail] ~]$ sudo chkconfig docker on #EC2起動時にDockerを自動で立ち上げる

このコマンドを想定しています。これを打つと、次の結果が返ってきます。これはエラーなんでしょうか。

Note: Forwarding request to 'systemctl enable docker.service'.

色々調べた末に次のコマンドを実行すると結果が何も出なかったため、設定できたかと思いec2再起動してブラウザで確認するとやはり502 Bad gatewayと出て、行き詰っている状況です。

[xxx@ip ~ home-study]$ sudo systemctl enable docker.service

他にお伝えするべき情報が抜け落ちていたらすみません。よろしくお願いします。

---

FROM ruby:2.5.3

RUN apt-get update -qq && \
    apt-get install -y build-essential \
                       libpq-dev \
                       nodejs \
                       vim
RUN apt-get update && apt-get install -y unzip && \
    CHROME_DRIVER_VERSION=`curl -sS chromedriver.storage.googleapis.com/LATEST_RELEASE` && \
    wget -N http://chromedriver.storage.googleapis.com/$CHROME_DRIVER_VERSION/chromedriver_linux64.zip -P ~/ && \
    unzip ~/chromedriver_linux64.zip -d ~/ && \
    rm ~/chromedriver_linux64.zip && \
    chown root:root ~/chromedriver && \
    chmod 755 ~/chromedriver && \
    mv ~/chromedriver /usr/bin/chromedriver && \
    sh -c 'wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -' && \
    sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list' && \
    apt-get update && apt-get install -y google-chrome-stable

RUN apt-get install -y vim

RUN mkdir /myapp

WORKDIR /myapp

ADD Gemfile /myapp/Gemfile
ADD Gemfile.lock /myapp/Gemfile.lock

RUN gem install bundler
RUN bundle install

ADD . /myapp

RUN mkdir -p tmp/sockets
RUN mkdir -p tmp/pids

docker-compose.yml↓

version: '3'
services:
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_USER: user
      MYSQL_PASSWORD: 1234
      MYSQL_DATABASE: myapp_db
    volumes:
      - mysql-data:/var/lib/mysql
    ports:
      - "4306:3306"

  app:
    build: .
    command: bundle exec puma -C config/puma.rb
    volumes:
      - .:/myapp
      - public-data:/myapp/public
      - tmp-data:/myapp/tmp
      - log-data:/myapp/log

  web:
    build:
      context: containers/nginx
    volumes:
      - public-data:/myapp/public
      - tmp-data:/myapp/tmp
    ports:
      - 80:80

volumes:
  mysql-data:
  public-data:
  tmp-data:
  log-data:

database.yml↓

default: &default
  adapter: mysql2
  encoding: utf8
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  username: <%= ENV.fetch('MYSQL_USER') { 'root' } %>
  password: <%= ENV.fetch('MYSQL_PASSWORD') { 'password' } %>
  host: db

development:
  <<: *default
  database: myapp_development

test:
  <<: *default
  database: myapp_test

production:
  <<: *default
  adapter: mysql2
  encoding: utf8mb4
  charaset: utf8md4
  collation: utf8mb4_general_ci
  host: <%= Rails.application.credentials.rds[:host] %>
  database: <%= Rails.application.credentials.rds[:database] %>
  username: <%= Rails.application.credentials.rds[:username] %>
  password: <%= Rails.application.credentials.rds[:password] %>

Answer 1

中で何をやっているのかわかりませんが、ソースを乗せただけで動かしてなかったらアクセスできないのは当然です。

githubからクローンして、docker-compose up -dする

これはAWS上のEC2インスタンスで、ということでしょうか。

docker-compose stopするとアクセスできなくなります

これはアプリケーションを動かしているコンテナを止めているのだから、当然アクセスできなくなりますね。
動いているものを止めているのだから、正しい挙動です。

Note: Forwarding request to 'systemctl enable docker.service'.

Noteはエラーメッセージではないですが、注意すべきことです。
7.7 シグナルワード
このメッセージが出ているのは、serviceコマンドは古いコマンドであって現在はsystemctlコマンドによってサービスを管理するからですね。
古いAmazon LinuxだとRHEL6系だったのでserviceコマンドを使って管理していましたが、Amazon Linux2はRHEL7系でsystemctlコマンド（systemd）に切り替わりました。
ただ、serviceコマンドを使っても内部的にsystemctlコマンドを使って処理してくれているよ、というメッセージです。
Forwarding requestと書いてありますよね。

ちなみにここでやっている

sudo systemctl enable docker.service

は

ec2起動時にdockerコンテナを自動起動するような設定

ではなく
dockerのプロセスをサーバ起動時に自動起動するための設定です。
なので、これをやったところでコンテナが自動で立ち上がってくれるわけではありません。
ただしdockerのプロセスが立ち上がっていないとdocker-composeが実行できないと思うので必要なことではあります。

なので、必要なのはdocker-compose up -dをサーバ起動時に実行してくれるような設定ですね。
これをやるなら自分でスクリプトを作ってsystemdに登録する必要があります。
Systemdを使ってさくっと自作コマンドをサービス化してみる

さて、認識についてですが

・dockerコンテナごとec2サーバーに移してデプロイする今回のような場合、コンテナが常時起動していることをもってデプロイ完了となる。

「デプロイ」自体の定義は配置することなので、どこまでをデプロイとするかによって変わります。
配置することとともにサーバ上で動いていることを求めているのなら、配置後にコンテナを起動させてアクセスができるようになっていることをもって完了とすればよいでしょう。
現実的には認識されたような見方をすることにはなるでしょう。

・今回の問題は、ec2起動時にdockerコンテナを自動起動するような設定がなされていないために起こっている。

これは関係ないです。
自分で手動でコマンドを打って止めているからです。

・もしコンテナを自動起動する設定ができれば、あとはawsのサイトからec2インスタンスを再起動しさえすれば常時サイトにアクセス可能となる。

これ自体は間違ってないですが、デプロイのたびにインスタンスを再起動する必要はないです。
Dockerコンテナの構成について記載がないので細かくはわかりませんが、
基本的にはDockerコンテナを立て直せばいいだけではないでしょうか。

Comments

[nippledrill]

>>自分で手動でコマンドを打って止めているからです。
この一文で気づきました。
デプロイはできているが自分でアクセスできないようにしていたということですね笑
もしPCを閉じたらec2サーバー上のコンテナも停止するなどと勘違いをしておりました。
ec2インスタンスの中でdocker-compose up -dしたら後はそのままにしといて良かったんですね。
またsystemdについても教えて頂き、ありがとうございます。

恐れながらまた初歩的な質問をしたいのですが、
>>デプロイのたびにインスタンスを再起動する必要はないです。
>>基本的にはDockerコンテナを立て直せばいいだけではないでしょうか。
これに関連するのですが、ローカルでVSCODEなどを使ってコードを変更して、それを本番用にも反映させたいときの手順についての私の認識が合っているかお聞きしたいです。
コードをいじる→コミット→ec2ログイン→git pull→docker-compose buildの順で合ってますでしょうか？
本文に関連してそうなファイルを追記しますので、もし可能であれば教えて頂けると嬉しいです。

[yu_1985]

> もしPCを閉じたらec2サーバー上のコンテナも停止する

PCを閉じたらではないですが、ただコマンドを打つだけではサーバからログアウトしたらdocker-composeコマンドが停止する場合があります。
そうならないために -d オプションをつけてデーモン化しています
https://docs.docker.jp/compose/reference/up.html

> コードをいじる→コミット→ec2ログイン→git pull→docker-compose buildの順で合ってますでしょうか？

デプロイが手動であるという前提ですが
docker-compose.ymlを見る限りコードをコンテナの中に含めずにコンテナにボリュームをアタッチしてソースを読み込んでるのでビルドはいらないと思います。
そしてビルドしただけでは立ち上がらないかと。
git pullしたあとにdocker-composeを落としてもう一回立ち上げればいいだけでしょう。

余裕があれば、そこを手動ではなくて自動化してみることにトライしてみてください。

[nippledrill]

>>git pullしたあとにdocker-composeを落としてもう一回立ち上げればいいだけでしょう。
なるほどです。ありがとうございます！
capistranoにもトライしてみたいと思います！

[yu_1985]

capistranoもいいですが、ゆくゆくはcapistranoでやっている構成やデプロイの流れを読み解きつつ、別の方法で実現してみましょう。
AWSにはCI/CD周りのサービス（Codeシリーズ）があるのでそれを触ってみるのもいいでしょう。