【AWS】VPCのレンジは自由に決めてはいけない
結論
10.0.0.0 – 10.255.255.255 172.16.0.0 – 172.31.255.255 192.168.0.0 – 192.168.255.255
理由
プライベートIPアドレスのレンジは決まっているから。 つまり↓のレンジ＝プライベートIPアドレス。
10.0.0.0 – 10.255.255.255 172.16.0.0 – 172.31.255.255 192.168.0.0 – 192.168.255.255
もしVPCを20.0.0.0/16のように作ってしまったら、万が一外部のサーバのIPアドレスがその 20.0.x.x 台にある場合、アクセス出来なくなる。
VPCは10.1.0.0/16, 10.2.0.0/16のように作っていくのが良さそうだ。
【Docker】docker-composeのvolumesではホストのファイルがコンテナのファイルを上書きする
DockerfileのRUNとCMD、docker-compose.yaml内のマウントタイミング - Qiitaより引用
docker-compose.yamlでマウントしたファイルに対して、Dockerfileで操作したいときは RUNではなくCMDを使う。
順番は、RUN→volumes→CMDだ。
この順番を忘れて定期的にハマっている。 具体的にはDockerfile内でライブラリをインストールしたはずなのに、ライブラリが見つからない、というパターン。
# NG FROM node:16-alpine WORKDIR /usr/src/app COPY package*.json /usr/src/app/ RUN npm i COPY . /usr/src/app EXPOSE 3000 CMD "npm" "run" "dev"
volumes: - ./:/usr/src/app
このように書いた場合、マウント時にホストのnode_modulesがコンテナのnode_moudulesを上書きしてしまう。volumesにおけるマウントはホストのファイルシステムが優先される。
つまり、せっかくのRUN npm iが無駄になってしまう。なぜなら実行される順番は RUN→ volumes→ CMDだから。解決策としてはCMDにnpm iを持ってくる。
# OK FROM node:16-alpine WORKDIR /usr/src/app COPY package*.json /usr/src/app/ COPY . /usr/src/app EXPOSE 3000 CMD "sh" "-c" "npm install && npm run dev"
↑のように書けば、volumesでファイルシステムが同期された後にnpm iでコンテナにnode_moudulesができて、それがホストにやってくる。
Dockerにおける開発環境構築では最後にCMDで ライブラリーのインストール && サーバー起動というのが1つの鉄板パターンなのかもしれない。
【Docker】Go 1.17 + Air で環境構築
Dockerfileを書く
FROM golang:1.17-alpine RUN mkdir /go/src/app WORKDIR /go/src/app RUN go install github.com/cosmtrek/air@v1.27.3 COPY . . EXPOSE 8080 CMD "sh" "-c" "go mod tidy && air -c .air.toml"
キャッシュを使ってビルドを高速化するために、RUN go install github.com/cosmtrek/air@v1.27.3は COPY . .の前に書くのが良い。
COPY 命令を処理するにあたり、 <コピー元> の内容が変更されている場合は、その Dockerfile の対象行以降でキャッシュを無効にします。
つまりソースコードが変更されるたびに COPY . .以下の go mod tidyが実行されるのだ。go install airはソースコードが変わっても毎回実行する意味がない。
だからCOPYより上に書いて常にキャッシュされるようにしておく。
docker-compose.ymlを書く
version: "3.8" services: go: build: context: . dockerfile: Dockerfile ports: - "8080:8080" tty: true volumes: - .:/go/src/app
【Goland】外部パッケージをimportする時にエディタ上でエラーになる時の対処法
問題
go.modを作る。
$ go mod init
main.goにimport "github/hoge/huga"を書く。
$ go mod tidy
という手順でパッケージをインストールした。しかしmain.goではimportのところでエディターがエラーを吐いている。
エディターがパッケージを見つけられていないようだ。しかし実際はちゃんと動く。
解決策
Golandの設定からモジュール統合を有効にする。
【Golang】go get とgo installの違い
go.mod
go getをすると中身が変わる。自分で触るファイルではない。
go get
このコマンドはgo.modを書き換えてソースコードのダウンロード、ビルド、インストールを行う。
環境変数GOMODCACHEで指定されているディレクトリにダウンロードされる。
コマンドのインストールで go getを使うのは非推奨。コマンドとはmainパッケージをビルドしたバイナリファイルのこと。
go mod tidy
main.goなどに import "github.com/hoge"と記述して、go mod tidyをすれば勝手にインストールされる。
go install
GitHub上からパッケージをインストールするときにmainパッケージが存在するものに対して使う。
mainパッケージがないリポジトリを指定するとエラーになる。
mainパッケージがないものをインストールするときは go getかソースコードにimportを記載して、go mod tidyをする。
まとめ
GitHubからパッケージをインストールする方法は2つ。mainパッケージを持つものにはgo installを使う。→コマンドになる。
それ以外はソースコードに importを書いて go mod tidyをする。
docker-composeでコンテナへの通信が届かない時の対処法
問題
docker-compose.ymlにポート番号を書いているのに、$ docker-compose run --rm container_name shでコンテナの中に入ってサーバを立てても
http://localhost:3000/へアクセスできない。
ports: - "3000:3000"
原因
docker-compose runは--service-portsというオプションを付けないと、ポートマッピングが無視されるから。
docker-compose run --rm --service-ports container_name shもしくは docker-compose run --rm -p 3000:3000 container_name shとすればOK！
WebStormで保存時にPrettierが効かない時の対処法
原因
nodeのバージョンがおかしいから。
自分は2つのプロジェクトを担当している。1つはnodeのバージョンが古いアプリケーション。もう1つはnode16をDockerに入れている新しいアプリケーションだ。
コーディング中にESLintを使いたいのでnode_modulesはコンテナの中だけじゃなくてホスト側にも設置している。
ESLintはnodeのバージョンが違うと実行できなくてエラーを吐くが、保存時に実行されるprettierはエラーを吐かない。
解決策
nやnvmなどを使ってnodeもバージョンをその都度変える。非常にめんどくさいがこれしかないと思う。
