こんにちは！バックエンドとインフラを勉強中のこのぴーです
前回はDockerイメージを軽量化する方法について解説しましたが、今回はDockerでNode.jsアプリケーションを動かす際に色々と考慮しなければいけない点があるのでそのあたりを解説していこうと思います

また、今回作成するDockerfileや.dockerignoreはGitHub上から確認できます

やってしまいがちな例

まず、悪い例として何も考えずにexpressのサーバをDockerを使って立ててみます

index.js (expressのドキュメントより引用)

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

package.json

{
  "name": "nodejs-docker",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "conop",
  "license": "MIT",
  "dependencies": {
    "express": "^4.18.1"
  }
}

Dockerfile

FROM node
WORKDIR /app
COPY . .
RUN yarn install
CMD "yarn" "start"

ビルドと実行

docker build -t nodejs-docker .
docker run -p 3000:3000 nodejs-docker
>> yarn run v1.22.18
>> $ node index.js
>> sample app listening on port 3000

curl localhost:3000
>> Hello World!

とりあえずちゃんと動いていることが確認できたのでコンテナを停止します

docker kill `docker container ls -lq`
>> 9f0edd2ca969

サイズも一応確認しておきます

docker image ls nodejs-docker
>> REPOSITORY      TAG       IMAGE ID       CREATED             SIZE
>> nodejs-docker   latest    e460c9f1faa7   About an hour ago   1GB

およそ1GBでした

このDockerfileの何がダメなのか

アプリケーションがちゃんと動作したのでこれで良いと思うかもしれませんが、いくつかのバッドプラクティスが含まれてしまっています

ベースイメージが大きい・バージョンの指定がされていない

nodeイメージにはたくさんのツールやパッケージが含まれているためサイズが大きくなってしまい、ダウンロードやビルドに時間がかかる上、脆弱性が生まれる原因ともなります
また、バージョンが指定されていないとビルドするたびにnodeのバージョンが上がりアプリケーションが正常に動作してくれない可能性があります

package.jsonのdevDependenciesまでダウンロードされてしまう

本番環境でアプリケーションを動作させる場合はyarn add -Dで追加するテストツールやeslintなどのリンタは不要です
その分イメージサイズが大きくなってしまうのでdependenciesのみダウンロードされるようにします

ソースコードを変更した際にレイヤーのキャッシュが利用されない

Dockerfileの3行目でソースコードとpackage.jsonが同時にコピーされています
こうするとパッケージの追加や削除が無くてもコードを変更するだけで再ビルドした際にyarn installが走ってしまいます

5行目のCMDがshell形式になっている

CMD "yarn" "start"のように文字列のみで記述するのをshell形式、CMD ["yarn" "start"]のようにJSON配列の形式で記述するのをexec形式といいます
shell形式で記述するとPID 1のプロセスがシェルとなり、kubernetesなどのオーケストレータから送られたシグナルがアプリケーションまで伝搬しない可能性があります
実際に、コンテナを動かしているプロンプト上でCtrl+Cを押してもコンテナが停止しないのが分かります

NODE_ENV環境変数にproductionが指定されていない

Expressを含むいくつかのライブラリではNODE_ENVという環境変数にproductionが設定してあると、本番環境用の最適化が行われるため設定しておくと良いです

アプリケーションがrootで実行されている

もしアプリケーションにOSコマンドインジェクションやディレクトリトラバーサルなどの脆弱性があり、それが悪用された場合アプリケーションがroot権限で実行されていると悲惨なことになります

.dockerignoreが設定されていない

.dockerignoreは.gitignoreと同じようにnode_modulesや.git、.envなどの本番環境で不要だったり、機密情報が含まれているファイルがイメージに含まれないように弾くための設定を記述するファイルです
不要なファイルが入っているとイメージサイズが大きくなったりビルドに時間がかかるようになります

マルチステージビルドを使用していない

前回の記事でも紹介しましたが、マルチステージビルドを使用して実行用の環境には最低限の物しか残さないようにします

実際に改善していく

それでは、前節で出てきたダメな点を解消していきます

ベースイメージを小さくし、バージョンも固定する

今回はパッケージをインストールしてExpressを動作させるだけなのでalpineイメージを使用します
また、nodeのバージョンもLTSの16系へ固定します

FROM node:16-alpine3.15
WORKDIR /app
COPY . .
RUN yarn install
CMD "yarn" "start"

ビルドしてサイズを確認します

docker build -t nodejs-docker .
docker image ls nodejs-docker
>> REPOSITORY      TAG       IMAGE ID       CREATED         SIZE
>> nodejs-docker   latest    d804656bebb0   5 seconds ago   119MB

イメージを変更する前の9分の1になりました

package.jsonのdependenciesのみダウンロードするようにする

yarn installをする際に--prodフラグを付けるとdevDependenciesにあるパッケージがダウンロードされなくなります
また、--frozen-lockfileフラグを付けるとyarn.lockが更新されず、パッケージの更新が必要な場合は失敗するようになるのでこちらも付けておきます

FROM node:16-alpine3.15
WORKDIR /app
COPY . .
RUN yarn install --prod --frozen-lockfile
CMD "yarn" "start"

コードを変更してもパッケージの再インストールが行われないようにする

ADDとCOPY命令は、イメージに含まれるファイルのチェックサムが計算され、ファイルに変更があればキャッシュが無効化されます
そのため、頻繁に行われないpackage.jsonとyarn.lockを先にコピーしておきyarn installを実行することでコードを変更してもいちいち再インストールが行われないようにします

FROM node:16-alpine3.15
WORKDIR /app

COPY package.json yarn.lock ./
RUN yarn install --prod --frozen-lockfile

COPY . .
CMD "yarn" "start"

CMDの内容を変更する

先ほど説明したようにCMDをshell形式で記述すると/bin/sh -c "yarn start"のようになり、アプリケーションまでイベントのシグナルが伝搬しません
そのため、exec形式で記述することでイベントが届くようにします
CMD ["yarn", "start"]
こうすることで、直接yarnが実行されイベントをnodeのruntimeに転送してくれますが、すべてのイベントを転送してくれるわけではありません
すべてのシグナルを受信するためにyarnを使わずnodeを直接叩くようにします
CMD ["node", "index.js"]

これで良いと思うかもしれませんが、このままだと意図しない動作を起こしてしまいます
実際にコンテナを動かし、docker stopでSIGTERMを送って停止させてみます

docker stop `docker container ls -lq`
docker container ls -la
>> CONTAINER ID   IMAGE           COMMAND                  CREATED          STATUS                       PORTS     NAMES
>> 7b9e05565509   nodejs-docker   "docker-entrypoint.s…"   10 minutes ago   Exited (137) 9 minutes ago             focused_mestorf

10秒ほど経ってからコンテナが停止したと思います
また、コンテナの終了コードは137です

ドキュメントにあるように、Node.jsのシグナルを受信した場合の終了コードは128にシグナルコードの値を加えたものです
そのため、今回は137 - 128 = 9ということでSIGKILLで強制終了させられていることが分かります
DockerはSIGTERMを送ってから10秒経っても終了しない場合にSIGKILLを送信して強制終了さるので、なぜかSIGTERMが無視されているということになります

原因はnodeがPID 1で動作していることにあります
Linux環境において、PIDが1のプロセスはinitプロセスです
そして、Node.jsはPID 1で動くように設計されておらずSIGTERMなど一部のシグナルが効かない、ゾンビプロセスが生きたままになるといった現象が起きてしまうことがあります
それを回避するためにlightweight init systemというツールがあります
このツールをPID 1で動作させ、nodeをその子プロセスにすることでイベントがちゃんと伝達し、ゾンビプロセスも修了するようにできます

実際に組み込んでみます
今回はTiniを使います
README.mdの通りにDockerfileを編集していきます

FROM node:16-alpine3.15
WORKDIR /app

RUN apk add --no-cache tini

COPY package.json yarn.lock ./
RUN yarn install --prod --frozen-lockfile

COPY . .

ENTRYPOINT ["/sbin/tini", "--"]
CMD ["node", "index.js"]

これでちゃんとSIGTERMでコンテナが停止するか確認します

docker stop `docker container ls -lq`
docker container ls -la
>> CONTAINER ID   IMAGE           COMMAND                  CREATED         STATUS                       PORTS     NAMES
>> d82f65ffb00c   nodejs-docker   "/sbin/tini -- node …"   2 minutes ago   Exited (143) 2 minutes ago             quirky_lewin

今度は10秒待たずにコンテナが停止し、ステータスも143(SIGTERMは15番なので128 + 15 = 143)となっていることが確認できました

NODE_ENV環境変数にproductionを設定する

Expressのドキュメントにもあるように、NODE_ENVにproductionが設定されているといくつかの恩恵がありますそのためDockerfileにENV NODE_ENV productionを追加します

アプリケーションをrootで実行されないようにする

alpineを含むnodeイメージにはnodeという名前のユーザとグループがデフォルトで存在しているのでこのユーザを使用します
また、ファイルをコピーしてくる際に--chown=user:groupを指定することでファイルの所有者もnodeユーザ・グループに変えるようにします

FROM node:16-alpine3.15
ENV NODE_ENV production

WORKDIR /app

RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]

COPY --chown=node:node package.json yarn.lock ./
RUN yarn install --prod --frozen-lockfile

COPY --chown=node:node . .

USER node
CMD ["node", "index.js"]

.dockerignoreを設定する

.dockerignoreは.gitignoreと同じような記述方法で作成します
今回は.git、node_modules、README.md、.gitignoreが不要なのでそれらを弾くように設定します

.dockerignore

.git
node_modules
README.md
.gitignore

これで不要なファイルがイメージ内に取り込まれないようになりました

マルチステージビルドを使うようにする

実行環境に必要な物だけを含めるためマルチステージビルドを使っていきます
パッケージのインストール、tiniの取得をnode:16-alpine3.15イメージ上で、実行をgcr.io/distroless/nodejs:16イメージ上で行います
tiniはdistrolessイメージ上で動かすためにapkで取得するのではなくGitHub上からバイナリを直接取得するように変更しました

FROM node:16-alpine3.15 as builder

WORKDIR /app

ENV TINI_VERSION v0.19.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static /tini
RUN chmod +x /tini

COPY package.json yarn.lock ./
RUN yarn install --prod --frozen-lockfile

FROM gcr.io/distroless/nodejs:16
ENV NODE_ENV production

WORKDIR /app

COPY --from=builder --chown=nonroot:nonroot /tini /tini
COPY --from=builder --chown=nonroot:nonroot /app/node_modules ./node_modules
COPY --chown=nonroot:nonroot . .

USER nonroot
EXPOSE 3000

ENTRYPOINT [ "/tini", "--", "/nodejs/bin/node" ]
CMD ["/app/index.js"]

さいごに

これでいくつかのベストプラクティスを採用したDockerfileが出来上がりました
ビルドしてサイズを確認してみます

docker build -t nodejs-docker .
docker image ls nodejs-docker
>> REPOSITORY      TAG       IMAGE ID       CREATED          SIZE
>> nodejs-docker   latest    4ef22942ad14   33 minutes ago   111MB

ベースイメージにalpineを使用したときとあまり変わっていませんが、最初よりも軽量化することができました
今日紹介した方法以外にもDockleやdocker scan(snyc)を使用した脆弱性のスキャンや、sha256のダイジェスト値を利用したベースイメージの検証、hadolintを使用したlintingなどを行うことでよりセキュアなイメージを作成するこが可能です

Shinonome Tech Blog

DockerでNode.jsを動かすときのベストプラクティス

やってしまいがちな例

このDockerfileの何がダメなのか

ベースイメージが大きい・バージョンの指定がされていない

package.jsonのdevDependenciesまでダウンロードされてしまう

ソースコードを変更した際にレイヤーのキャッシュが利用されない

5行目のCMDがshell形式になっている

NODE_ENV環境変数にproductionが指定されていない

アプリケーションがrootで実行されている

.dockerignoreが設定されていない

マルチステージビルドを使用していない

実際に改善していく

ベースイメージを小さくし、バージョンも固定する

package.jsonのdependenciesのみダウンロードするようにする

コードを変更してもパッケージの再インストールが行われないようにする

CMDの内容を変更する

NODE_ENV環境変数にproductionを設定する

アプリケーションをrootで実行されないようにする

.dockerignoreを設定する

マルチステージビルドを使うようにする

さいごに

新歓ハンズオン資料編集後記

技術力がなくても誰かの役に立てるよねと言うお話

AWS SDK for Python (Boto3)で技術課題を解決した話

DockerのVolumes・Bind mount・tmpfs mountsの違いと使い方

Djangoを使うときに知っておきたいDBの基礎知識とN+1問題

Github Actionsのすすめ

Shinonome Tech Blog

やってしまいがちな例

このDockerfileの何がダメなのか

ベースイメージが大きい・バージョンの指定がされていない

package.jsonのdevDependenciesまでダウンロードされてしまう

ソースコードを変更した際にレイヤーのキャッシュが利用されない

5行目のCMDがshell形式になっている

NODE_ENV環境変数にproductionが指定されていない

アプリケーションがrootで実行されている

.dockerignoreが設定されていない

マルチステージビルドを使用していない

実際に改善していく

ベースイメージを小さくし、バージョンも固定する

package.jsonのdependenciesのみダウンロードするようにする

コードを変更してもパッケージの再インストールが行われないようにする

CMDの内容を変更する

NODE_ENV環境変数にproductionを設定する

アプリケーションをrootで実行されないようにする

.dockerignoreを設定する

マルチステージビルドを使うようにする

さいごに

新歓ハンズオン資料編集後記

技術力がなくても誰かの役に立てるよねと言うお話

関連する投稿

AWS SDK for Python (Boto3)で技術課題を解決した話

DockerのVolumes・Bind mount・tmpfs mountsの違いと使い方

Djangoを使うときに知っておきたいDBの基礎知識とN+1問題

Github Actionsのすすめ

人気のタグで検索する