はじめに

先日、Docker コンテナ上で spago repl を動かすことができたので、今回は spago init で作成したプロジェクトのビルド、実行を確認する
Docker コンテナ上で PureScript を動かす - Qiita

検証環境

Windows10 Home Edition
VirtualBox 6.1.16
docker-machine.exe version 0.16.1, build cce350d7

# Docker Host OS (CoreOS)
$ uname -a
Linux default 4.14.154-boot2docker #1 SMP Thu Nov 14 19:19:08 UTC 2019 x86_64 GNU/Linux

Docker version 19.03.5, build 633a0ea838
docker-compose version 1.26.0, build d4451659

ディレクトリ構成

purescript フォルダの中に docker-compose.yml と Dockerfile と空フォルダの myapp を準備する

purescript
├── docker-compose.yml
├── Dockerfile
└── myapp

docker-compose.yml

docker-compose.yml

version: "3.7"
services:
  purescript:
    build:
      context: .
      dockerfile: Dockerfile
      target: "purescript"
    image: takaya030/purescript
    command: "true"
  app:
    build:
      context: .
      dockerfile: Dockerfile
      target: "pure-app"
    image: takaya030/pure-app
    volumes:
      - ./myapp:/home/pureuser/myapp
    working_dir: /home/pureuser/myapp
    command: "spago run"

Dockerfile

Dockerfile

FROM node:12 as purescript
LABEL maintainer "takaya030"

# install purescript
RUN npm install --global --unsafe-perm purescript spago

# add user
RUN userdel node && \
    useradd -m -s /bin/bash pureuser

WORKDIR /home/pureuser
USER pureuser

RUN mkdir tmp && cd tmp && spago init

CMD cd tmp && spago repl

#=========================================
FROM purescript as pure-app

COPY ./myapp /home/pureuser/myapp
WORKDIR /home/pureuser/myapp

CMD ["spago","run"]

イメージのビルド

$ cd purescript
$ docker-compose build purescript
$ docker-compose build app

イメージの確認

$ docker images
REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
takaya030/pure-app     latest              c018082fc97b        27 hours ago        1.08GB
takaya030/purescript   latest              fb50aeb56d04        2 days ago          1.08GB
node                   12                  1f560ce4ce7e        5 weeks ago         918MB

プロジェクトの作成

下記のコマンドを実行すると myapp フォルダ以下に初期プロジェクトが作成される

$ docker-compose run --rm app spago init

プロジェクトのファイル構成

$ ls -l myapp
total 4
-rwxrwxrwx    1 docker   staff         2903 Nov 16 09:53 packages.dhall
-rwxrwxrwx    1 docker   staff          231 Nov 16 09:53 spago.dhall
drwxrwxrwx    1 docker   staff            0 Nov 16 09:57 src
drwxrwxrwx    1 docker   staff            0 Nov 16 09:53 test

ビルド

自分の環境ではサンプルプログラムの絵文字が文字化けするため、以下のように変更した

myapp/src/Main.purs

module Main where

import Prelude

import Effect (Effect)
import Effect.Console (log)

main :: Effect Unit
main = do
  log "Hello, PureScript"

下記コマンドでビルド

$ docker-compose run --rm app spago build

[info] Build succeeded.

実行

ビルドが成功したら下記コマンドで実行する

$ docker-compose run --rm app spago run

Hello, PureScript

参考

• 純粋関数型スクリプト言語PureScriptのはじめかた - Qiita

Dockerでdocker image push dockerIDというコマンドを実行した時

denied: requested access to the resource is denied
この様に表示された時はまず指定しているdockerIDが自分dockerIDがあっているかを確認する。

これでも解決されない時(preparingとwaitingまで出たけどまたdenitedが出た)は、
おそらくpermissionの問題だと思うので、
docker loginというコマンドを叩いてログインすれば正しくpushできるはず。

開発環境
macOS Big Sur

下記の記事を参考に環境構築を行ったのですが、
やれwgetコマンドが無いだの、apt-getコマンドが無いだの初心者の方への導入への障壁がいくつかあったため、
それを乗り越えるための記事にしたいと思います。（※注：下記の記事は決して悪くありません。）

タイトル	リンク
5分で作るLaravel＋Vue.js開発環境（docker-compose）	https://qiita.com/yusukeito58/items/37bd551560e495dbd1b8

---

wgetコマンドインストール

タイトル	リンク
Mac - wgetコマンドをインストール（使えるようにする）	https://qiita.com/th4inf/items/f85c1b91065d85af67b9

---

apt-getコマンドインストール ←apt-getコマンドが無いかと思い調べてが結果的にいらないのでやらんで良い

タイトル	リンク
install apt-get to Mac	https://qiita.com/th4inf/items/f85c1b91065d85af67b9

---

docker-compose up -d --build時にmysql-clientのエラーがでたら

エラー内容

E: Package 'mysql-client' has no installation candidate
ERROR: Service 'app' failed to build : The command '/bin/sh -c apt-get update     && apt-get install -y zlib1g-dev mysql-client libpng-dev libjpeg-dev gnupg curl wget     && docker-php-ext-configure gd --with-png-dir=/usr/include --with-jpeg-dir=/usr/include     && docker-php-ext-install zip pdo_mysql gd' returned a non-zero code: 100

タイトル	リンク
docker-compose buildするときにbundle installやmysql-clientでコケた話	https://qiita.com/aseanchild1400/items/d3580366054fee3d2703

---

概要

コンテナを立ち上げるときにエラーが起きたので、その対処法とコマンドをまとめておきます。

エラー文

ターミナル

Error response from daemon: Conflict. The container name "コンテナ名" is already in use by container "コンテナID". You have to remove (or rename) that container to be able to reuse that name.

コンテナがすでにあるので、名前を変更するか削除するかしてください。要するに同じコンテナ名は複数つくれないということですね！！

仮説

• 動作しているコンテナ一覧を見る。
• 動作を止め、コンテナ削除。

必要になるコマンド

Dockerコマンド	備考
docker ps	動作中コンテナ一覧
docker ps -a	コンテナ一覧
docker stop コンテナID	動作しているコンテナをストップ
docker rm (-f) コンテナID	停止しているコンテナを削除 ※-fオプションを付けると強制削除

注意が必要なのが、コンテナをストップしてからでないとコンテナ削除ができないこと。
動作しているコンテナを停止コマンドで停止させたあと、そのまま削除するのではなく、動作していたコンテナが停止できたのか？を確認をしてから削除する。また、削除に成功したあとも削除できたのか確認する。
もしくは-fオプションで強制的に削除してしまえばコンテナ起動中でも削除可能。

このようにいちいち確認する癖をつけておけば後で痛い目に合う確率が減ると思いました。

再度コンテナ作成

Cookieが大きいというエラー。読み取るとおそらくCookieが溜まってるから削除して！！という感じだと思います。
早速溜まったCookieを削除し挙動を確認。

仮説通りnginxコンテナを実行することができました！！

まとめ

• コンテナは同じ名前のものを作ることができない。
• コンテナ削除とイメージ削除で少しコマンドが違う(rmi か　rm)ので削除に失敗しても落ち着く。
• rmiのiはイメージのことでiをremoving（取り除く）ということ。
• コマンドを打ったあと挙動が正しいか確認する癖をつける。

参考文献

この記事は以下の情報を参考にして執筆しました。

• Dockerイメージとコンテナの削除方法
• Chromeに「 400 Bad Request Header Or Cookie Too Large 」が出たときの対処方法

起こった事

go run ***.goでサーバーを立ちあげた後にエディターでgoファイルを編集するとgocode-gomodがかなりCPUを食いエディターがフリーズ＆PCが落ちてしまう、、、、

環境

• go 1.15.3
• docker
• VSCode

解決策

設定ファイル(setting.json)を開き以下のコードを追記すると治るそう

setting.json

{
  "go.useLanguageServer": true,
}

原因

https://github.com/golang/vscode-go/issues/249#issuecomment-647902730

goの候補表示してくれるgocode-gomodは現在メモリをかなり食ってしまうようになっているらしくメンテナンス中かつ開発がストップしているそう、、
なので、変わりにgoplsを使ってくれとの事でした！

これでgoでの開発に集中できる^^

Docker使っててMySQLのコンテナが立ち上がらない現象にでくわしました。
原因はわかってないですが解決したので、一旦メモを残します

環境

• Docker Desktop ver 2.5.0.1
• Docker Compose ver 1.27.4
• MySQL 8

先に結論

Use gRPC FUSE for file sharing をdisableにして Apply & Restart。

起きたこと

docker-compose up -d

を実行して

Creating network "xxx" with the default driver
Creating xxx_architecture_mysqldata_1 ... done
Creating xxx_mailhog_1   ... done
Creating xxx_architecture_mysql_1     ... done
Creating xxx                      ... done

の状態になったのですが、作業中にMySQL起因のエラーが発生。

確認してみる

docker ps

まず

docker ps

で何が立ち上がっているのか確認しましたが、MySQLのコンテナは立ち上がっていないようでした。
docker execでMySQLのコンテナに入れるのか試してもみましたが...

Error response from daemon: Container コンテナID is not running

だめでした。

docker-compose upしたときはdoneと出ていたので立ち上がっているものと思っていましたが...。

ログを見てみる

とりあえずこういう時はログを見てみないとなんとも言えないので、とりあえずログを確認します。

docker logs コンテナID

ログはこんな感じ

2020-11-17 07:30:22+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.19-1debian10 started.
2020-11-17 07:30:23+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2020-11-17 07:30:23+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.19-1debian10 started.
2020-11-17T07:30:24.278825Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2020-11-17T07:30:24.279399Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 1
2020-11-17T07:30:24.298133Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2020-11-17T07:30:26.062069Z 1 [ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('2') and data dictionary ('0').
2020-11-17T07:30:26.064235Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2020-11-17T07:30:26.064751Z 0 [ERROR] [MY-010119] [Server] Aborting
2020-11-17T07:30:26.944800Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.19)  MySQL Community Server - GPL.

↓ここでなんか失敗してますね

2020-11-17T07:30:26.064235Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2020-11-17T07:30:26.064751Z 0 [ERROR] [MY-010119] [Server] Aborting

とりあえずbuildしなおしてみる

いろいろググるのがめんどくさくてbuildしなおしました。

docker-compose build --no-cache

buildが終わったので docker logs でログを見てみましょう。

2020-11-17 08:07:48+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.19-1debian10 started.
2020-11-17 08:07:49+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2020-11-17 08:07:49+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.19-1debian10 started.
2020-11-17T08:07:49.831146Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2020-11-17T08:07:49.831363Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 1
2020-11-17T08:07:49.854161Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2020-11-17T08:07:51.391894Z 1 [ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('2') and data dictionary ('0').
2020-11-17T08:07:51.392387Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2020-11-17T08:07:51.392606Z 0 [ERROR] [MY-010119] [Server] Aborting
2020-11-17T08:07:52.248666Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.19)  MySQL Community Server - GPL.

なおってへんやん

解決した方法

これ
https://stackoverflow.com/questions/64146845/mysql-not-starting-in-a-docker-container-on-macos-after-docker-update

Docker DesktopのPreferences > Experimental Features で
Use gRPC FUSE for file sharing
をdisableにしてApply & Restart

その後docker-compose upしたら普通に立ち上がりました。

ちなみに別プロジェクトではほぼ同じセッティングでMySQL5.7を使用しており、そちらではUse gRPC FUSE for file sharingがenableになっていても全く問題ありませんでした。
MySQLのバージョン違いで起こる問題なんでしょうか

Dockerfileとは

Docker imageを作る上での設計図。
Dockerfileから作成する事で、コンテナの中身が把握しやすくなる。
Dockerfileを作成し下記のコマンドでimageを作成する。

$ docker build -t <name> <directory>

Dockerfileの書き方

Dockerfileは基本的に、3つのinstructionから構成されている
・FROM
・RUN
・CMD

まずはFROMから書き始める。

FROM ubuntu:latest
RUN touch test
CMD ["ls"]

この例で例えると、ubuntuというOSイメージをFROMで作成を行い、Linuxのtouchコマンドを使えるようにする。
大体FROMにはOSを指定したり、他の人が作成したDocker imageを指定する事が多い。

RUNで指定した作業がLayerとして積み重なっていく。
但し、RUNを多用するとLayerが増えていき、Dockerimageが重たくなるので注意が必要。

CMDはDockerfileの最後に記述する。
CMDで指定したコマンドが、containerを作成するときに実行される。
ここではlsコマンドが実行される。

RUNとCMDの違いについて

端的にまとめると、RUNはLayerを作る。
CMDはLayerを作らない。
つまりCMDは、Dockerimageには反映されない。

Dockerimageに保存したい場合はRUNで記述し、実行したい内容はCMDに記述するイメージになります。

Layer数を軽量化するために...

Layerを作成するコマンドは三つある。
・RUN
・COPY
・ADD

実際の業務においてはRUNを主に使用し、パッケージを管理する事がメインになります。
パッケージを管理するコマンドが下記になります。

RUN　apt-get update　-新しいパッケージリストを取得
RUN　apt-get install <package> -<package>をインストール

これを&&で繋げる事によって、一行でまとまりLayerが軽量化される。

RUN apt-get update && apt-get install test

今回は以上です。

今回個人開発で制作したRailsアプリをCircleCIを使いコンテナデプロイさせることに成功したので、備忘録としてこちらに記載させていただきます。（またReadmeなど整い次第、実際のアプリも別記事で紹介させていただきます。）

こちらですが、長くなってしまったので記事を分けて書いていってます。

タイトル
① 下準備編 ←今ここ！
②-1 インフラ構築編
②-2 インフラ構築編(執筆中）
自動デプロイ編(執筆中）

また、現在私はwindows10を利用しており、macの方は適時置き換えて進めていってください。
といってもaws-ecs-cliのインストール方法が異なるぐらいで他は同じだと思います。（windowsだとインストールするのに少し手間がかかりました。）

それと、筆者はAWSのコンソールの言語はあえて英語で設定しているので、英語で設定していただいた方が本記事は進めやすいと思います。
（AWS CLIのコマンドの名前とコンソールの英語表記が一致するので、お勧めです。）

対象となる人

• AWSのアカウントを持っている人
• すでにDocker化されたRailsアプリがあり、インフラにAWSや、CI/CDツールを取り入れることにチャレンジしたい人
• 就活のポートフォリオとして上記の技術を取り入れたい人
• AWSに興味がある人
• macばっかでwindowsの記事がなくて困っている人

前提知識

• VPC、サブネットなどインフラに関する基礎知識
• CircleCI、Dockerの基礎知識

本記事で目指す構成

上記のような構成を目指します。

実際の流れを言葉で説明すると、

①Githubにpush(masterブランチ以外のときは自動テストとRubocopだけ実行される。)
②CircleCIがpushを検知して、ビルドを開始する。
③RSpecとRubocopをパスしたら、dockerイメージがビルドされ、ECRへpushされる。
④最新のDockerイメージを使い、ECSのタスク定義（ほぼdockerコンテナの起動方法を定義したもの、docker-compose.ymlみたいなものです）を更新する。
⑤EC2インスタンスが起動され、デプロイ完了。

また、実際作成した個人開発アプリではRoute53とACMを用いたSSL化ももちろん行っており、こちらでかなり苦労したので別記事としてまた書こうと思います。SSL化は実運用する上では必須なので必ずやりましょう。

環境

• windows10 Pro
• Rails: 6.0.3.2
• ruby: 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
• Docker for windows
• MySQL 5.7
• nginx:1.15.8
• puma:4.3.5

下準備

下準備編では、主に4つのことをやります。

• ツールのインストール
• IAMユーザーを作成し、実行権限（ポリシーといいます）の付与
• aws configureの設定
• キーペアの作成

ツールをインストールする

以下の2つをインストールします。

• awscli
• aws-ecs-cli

windowsの方はこちらの記事を参考に進めていけばインストールできると思います。私はこの通りにやってインストールできました。

これらのツールを使うことによってターミナルからVPC、サブネット、クラスターの作成、ECRへのpush、タスクの再定義などがいちいちコンソールをぽちぽちしなくても出来るようになります。

　IAMを作成する

コンソールにログインして、service を選択し、IAMと検索しクリック。

Usersをクリックし、Add user をクリック

一番右のAttach existing policiesをクリックし、以下の2つのポリシーをアタッチする。

• AmazonECS_FullAccess
• AmazonEC2ContainerRegistryFullAccess

確認画面で設定した通りにアタッチできているのが確認出来たら、Create userをクリック

すると、次画面でアクセスキーとシークレットキーが作成されます。csvでダウンロードみたいなボタンが表示されると思うので、それをクリックするなどして、情報を保存します。

シークレットアクセスキーを誤ってgitにpushしてしまい、何百万もの請求がAmazonから来た例もあるようなので、取り扱いには十分気を付けましょう。

ポリシーを追加する（権限付与）

• AmazonECS_FullAccess
• AmazonEC2ContainerRegistryFullAccess

さきほど、こちらのポリシーを付与しましたが、これだけではecs-cliのコマンドを実行するときに権限周りでエラーが発生してしまうので、別途追加していきます。

IAMのコンソールから、Policiesを選択し、Create Policiesを選択します。
画面にあるJsonタブをクリックし、以下のコードを入力してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:AddRoleToInstanceProfile",
                "iam:CreateInstanceProfile",
                "iam:CreateRole",
                "iam:DeleteInstanceProfile",
                "iam:DeleteRole",
                "iam:DetachRolePolicy",
                "iam:PassRole",
                "iam:RemoveRoleFromInstanceProfile",
                "ec2:DeleteInternetGateway",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteRouteTable"
            ],
            "Resource": "*"
        }
    ]
}

入力したら、Review policyをクリックします。

任意の名前と説明を入れ、Create policyをクリックします。

次に、作成したIAMユーザーに↑で新しく作成したポリシーを付与します。
Usersをクリックし、Add permissionsをクリック

Attach existing policies directlyをクリックし、先ほど作成したポリシーを選択

確認画面で、正しいポリシーが選択できていたらAdd permissionsをクリックします。

ターミナルで「aws configure」を実行する

aws configureを--profileオプションを付けてターミナルで実行します。
実行すると対話形式で聞いてきますのでひとつずつ正確に入力しましょう。

$ aws configure --profile 作成したユーザー名

AWS Access Key ID # 作成したときのアクセスキー
AWS Secret Access Key # 作成したときのシークレットアクセスキー
Default region name # ap-northeast-1 
Default output format # json 

aws configure を実行するとホームディレクトリ配下に.awsディレクトリが自動生成され、そこにアクセスキーなどの情報が以下のような感じで保管されますので、確認してみてください。（完全に一緒にはならないかも）

~/.aws/credentials

[ユーザー名]
aws_access_key_id=AKIAIOSFODNN7AJDIFK
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/gkjkAKJDKJ
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

~/.aws/config

[profile ユーザー名]
region = ap-northeast-1
output = json
[default]
region = ap-northeast-1
output = json

キーペアの作成

続いてキーペアの作成を行っていきます。

Service→EC2コンソール→key pair→Create key pairを選択し、適当なキーペア名を入力します。
ファイルの拡張子は.pemを選択し、Create key pairをクリックします。

完了すると.pemファイルが自動でダウンロードされるので、以下のコマンドを実行し、「.ssh」ディレクトリに移動して権限を変更します。

$ mv Downloads/sample-app.pem .ssh/
$ chmod 600 ~/.ssh/sample-app.pem

以上で下準備編は完了です！お疲れ様でした！
続きはインフラ構築編②-1へお進みください！

最後まで読んでいただきありがとうございます！

かなり長い記事になってしまったので、記載ミス等、何かご指摘などあればコメントいただけますと幸いです。