Linux サーバへのデプロイ

原文: Deploy to a Linux server ── © Louis Pilfold and the Gleam contributors, Apache-2.0。日本語訳 © 2026 Canonical。

このガイドでは、Gleam のバックエンド Web アプリケーションを 1 台の Linux サーバへデプロイする手順を説明します。アプリケーションは Linux コンテナ内に配置して systemd で実行し、HTTPS の処理には Caddy を使用します。

サーバを用意する

このチュートリアルでは、Ubuntu の最新の LTS バージョンを使用します。ほかの Linux ディストリビューションでも構いませんが、コマンドが少し異なったり、アプリケーションのデプロイに追加の手順が必要になったりする場合があります。

サーバをまだお持ちでない場合は、月々わずかな料金で利用できるホスティングサービスが多数あります。決まったプロバイダがなければ、Gleam の Vultr 紹介リンクをご利用いただくことも可能です。

ここでは、仮想 CPU 1 コアと 1GB のメモリを備えた amd64 サーバを使用します。もっと小さなサーバでも動作しますが、メモリは最低でも 250MB を推奨します。アプリケーションが大量のトラフィックを受けたり、重い計算を行ったりする場合は、より強力なサーバへのアップグレードをご検討ください。サーバを作成する際は、必ずご自身の SSH 公開鍵を登録してください。パスワードによる SSH 接続は安全ではないため、絶対に避けてください。

DNS を設定する

サーバを用意したら、サーバのパブリック IPv4 アドレスを指す A レコードを追加します。このアドレスは、たいていプロバイダの Web コンソールで確認できます。

サーバにパブリック IPv6 アドレスがある場合は、同じドメインにそのアドレスを指す AAAA レコードを追加します。

このチュートリアルの以降の手順では、ドメイン example.gleam.run を使用します。実際には必ずご自身のドメインに置き換えてください。

アプリケーションを準備する

アプリケーションが 0.0.0.0 でリクエストを待ち受けるように設定してください。Mist や Wisp をお使いの場合は、次のように mist.bind 関数で設定できます。

let assert Ok(_) =
  wisp_mist.handler(handle_request, secret_key_base)
  |> mist.new
  |> mist.bind("0.0.0.0") // <- この行を追加する
  |> mist.port(8000)
  |> mist.start_http

アプリケーションが起動するポート番号を覚えておいてください。このガイドの以降の手順では、ポート 8000 を使用します。

Dockerfile を追加する

リポジトリのルートディレクトリに、以下の内容で Dockerfile という名前のファイルを追加します。

FROM erlang:27.1.1.0-alpine AS build
COPY --from=ghcr.io/gleam-lang/gleam:v1.8.0-erlang-alpine /bin/gleam /bin/gleam
COPY . /app/
RUN cd /app && gleam export erlang-shipment

FROM erlang:27.1.1.0-alpine
RUN \
  addgroup --system webapp && \
  adduser --system webapp -g webapp
COPY --from=build /app/build/erlang-shipment /app
WORKDIR /app
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["run"]

2 つの FROM 行と最初の COPY 行にある Erlang と Gleam のバージョンは、ご使用の環境に合わせて書き換えてください。

アプリケーションの起動時に gleam run へ追加の引数を渡す必要がある場合は、その引数を含めるように CMD ["run"] の行を編集してください。

その他に必要な依存関係がある場合(たとえば NIF を使っていて C コンパイラが必要な場合など)は、該当するパッケージをインストールするようにこのファイルをさらに編集してください。

CI でコンテナをビルドする

ここでは GitHub Actions を使い、v で始まる Git タグ(たとえば v1.0.0 など)がリポジトリへ push されるたびに、Docker でコンテナイメージをビルドして GitHub コンテナレジストリへ公開するように設定します。

.github/workflows/build-container.yml というファイルを作成し、以下の内容を記述します。

name: Build container image
on:
  push:
    tags:
      - v*

jobs:
  push:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build . --file Dockerfile --tag webapp

      - name: Log in to registry
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin

      - name: Push image
        run: |
          IMAGE_ID=ghcr.io/gleam-run/example
          TAG="$IMAGE_ID":$(echo "${{ github.ref }}" | sed -e 's,.*/\\(.*\\),\\1,')
          docker tag webapp "$TAG"
          docker push "$TAG"

IMAGE_ID=ghcr.io/gleam-run/example の部分は、ご自身の GitHub リポジトリ名に書き換えてください。たとえばリポジトリが https://github.com/wibble/wob の場合、IMAGE_ID=ghcr.io/wibble/wob となります。

上記の変更を push したら、新しい Git タグを GitHub へ push してください。これでワークフローが起動し、実行の様子を GitHub リポジトリの「Actions」タブから確認できるようになります。

git tag production
git push --tags

ここでは production というタグを使用していますが、お好きなタグ名を使用して構いません。

SSH サービスを安全にする

先ほど設定したドメイン名を使用して、サーバへ SSH 接続します。

ssh root@example.gleam.run

SSH 接続できない場合は、ユーザ名とドメインが正しいこと、そしてサーバ作成時に登録したものと同じ SSH 鍵を使用していることを確認してください。

パスワードによる SSH ログインの許可はセキュリティ上のリスクとなるため、必ず無効化してください。まず、テキストエディタで /etc/ssh/sshd_config を開きます。

nano /etc/ssh/sshd_config

#PasswordAuthentication yes という行を探し、PasswordAuthentication no に書き換えます。行頭の # が外れていることに注意してください(元の設定には付いていたはずです)。

その後、SSH サービスを再起動します。

systemctl restart ssh

ファイアウォールでネットワークを守る

サーバへのアクセスは HTTP、HTTPS、SSH のみ許可すれば十分なので、それ以外の通信をブロックするように設定します。

ufw allow ssh
ufw allow http
ufw allow https
ufw enable

有効化する際、ufw が確認を求めてくることがあります。その場合は y と入力して承認してください。

Ubuntu のセキュリティ更新を自動化する

apt install --yes unattended-upgrades
systemctl start unattended-upgrades

Ubuntu Linux をお使いでない場合は、ご利用のディストリビューションにおける相当の手順を実施してください。

Caddy と Podman をインストールする

Caddy は、TLS 証明書の取得と HTTPS トラフィックの処理に使用するリバースプロキシです。一方 Podman は、アプリケーションのコンテナを実行するためのコンテナエンジンです。

どちらも apt コマンドでインストールします(Ubuntu Linux 以外の環境では、該当するパッケージマネージャを使用してください)。

apt install --yes podman caddy

インストール完了後に Web ブラウザでご自身のドメインへアクセスすると、Caddy のデフォルトのホームページが表示されるはずです。

Podman のコンテナを定義する

プライベートな GitHub リポジトリを使用している場合は、GitHub のセキュリティ設定から read:packages 権限を持つパーソナルアクセストークンを作成し、それを使ってサーバ上でログインする必要があります。

echo "YOUR_GITHUB_PAT" | podman login ghcr.io -u YOUR_GITHUB_USERNAME --password-stdin

次に、Podman 用の systemd コンテナファイルを作成します。

nano /etc/containers/systemd/webapp.container

以下の内容を記述します。その際、Image=ghcr.io/gleam-lang/example:production の行はご自身の GitHub リポジトリ名に変更してください。

[Unit]
Description=My Gleam web application
After=local-fs.target

[Container]
Image=ghcr.io/gleam-lang/example:production
PublishPort=8000:8000

[Install]
WantedBy=multi-user.target default.target

コンテナの追加設定を行いたい場合は、[Container] セクションを編集するとよいでしょう。

アプリケーションが別のポートでリクエストを待ち受けている場合は、8000 の部分を実際のポート番号に書き換えてください。

環境変数を追加する場合は、Environment=KEY=value という構文を使用します。

サーバ上のディレクトリをコンテナ内のアプリケーションから参照できるようにするには、Volume=/path/on/server:/path/in/container:rw,z という構文を使用します。

詳細については、Podman systemd のドキュメントを参照してください。

コンテナを起動する

作成した .container ファイルによって systemd のサービスが作られるため、アプリケーションのコンテナは systemctl コマンドで管理できるようになります。

systemd デーモンをリロードしてファイルの最新版を読み込ませたあと、サービスを起動します。

systemctl daemon-reload
systemctl start webapp

systemd サービスの状態は、systemctl status webapp コマンドで確認できます。

アプリケーションが待ち受けているポートに対して localhost でリクエストを送信し、サービスが HTTP リクエストを正常に処理できているか確認します。

curl -I localhost:8000

Caddy がアプリケーションへトラフィックを送るよう設定する

/etc/caddy/Caddyfile の内容を以下の記述に置き換えます。ドメイン名とポート番号は必ずご自身の環境に合わせて変更してください。なお、localhost の部分はそのまま残します。

example.gleam.run {
		reverse_proxy localhost:8000
}

変更を反映させるため、Caddy サービスを再起動します。

systemctl restart caddy

Web ブラウザでご自身のドメインを開いてみてください。HTTPS で保護された Web サイトが表示されるはずです！

今後のデプロイと保守

GitHub リポジトリへ新しいタグを push すると、新しいコンテナイメージがビルドされます。また、タグを新しいコミットへ force-push することで、同じ名前で新しいコンテナイメージを作成することも可能です。

.container ファイルを変更した場合は、デーモンをリロードして変更を読み込ませたあと、サービスを再起動してください。これにより、新しい設定を適用したコンテナへ置き換わります。

systemctl daemon-reload
systemctl restart webapp

実行ログは、journalctl -xeu webapp コマンドで確認できます。