Dokkuを小規模PaaSとして使う前に確認するサーバー要件

Dokkuの役割と対象範囲

dokku/dokkuは、READMEでDockerを使ってアプリケーションのライフサイクルを管理するPaaSと説明されています。プロジェクト自身はDocker powered mini-Herokuという表現を使いますが、これは製品の位置付けを示す説明です。素材時点のGitHub情報ではstarsは32,113、forksは2,069、open issuesは29で、既定ブランチはmasterです。公開リポジトリの数値は活動の目安であり、利用環境での安定性を直接証明しません。

Dokkuを選ぶと、アプリケーションを動かすサーバー、OS更新、SSHアクセス、ドメイン、データの扱いを利用者側で管理します。クラウドPaaSの管理範囲をそのまま移すものではないため、導入前に誰がホストを保守し、障害時にどのデータを復旧するかを決めておく必要があります。

対応OSと初期サーバー

READMEの要件は、Ubuntu 22.04または24.04のamd64、arm64と、現在サポートされているUbuntuリリースです。Debianは11以降のamd64、arm64が挙げられています。前提は新しいVMで、インストールを実行する利用者はsudoへアクセスできなければなりません。OSの版だけでなく、CPUアーキテクチャと既存サービスの有無を確認してください。

Dokkuの導入先にすでに別のWebサーバーやコンテナ基盤がある場合、ポートやプロキシの競合を事前に洗い出します。READMEは動作に必要なクラウド事業者、ディスク容量、バックアップ構成の数値を示していません。最初のVMは本番と分け、実際のアプリケーションを一つ置いて必要な資源を観測する方が判断しやすくなります。

SSH鍵が導入後の入口になる理由

READMEは、アプリケーションのデプロイに使えるSSH鍵ペアを要件として挙げています。インストール前に鍵が存在すればDokkuへ自動で取り込まれ、存在しない場合はdokku ssh-keys:addを使って手動で登録します。この説明から、アプリケーションの配置経路はサーバーへのログイン用鍵とは別に、Dokkuが認識する公開鍵の管理にも依存すると分かります。

実運用では、誰の鍵を登録したか、退職や端末交換のときにどう失効させるか、デプロイ用鍵の共有をどう避けるかを記録します。READMEは鍵のローテーション、複数環境の分離、監査ログの詳細までは説明していません。まずテスト用鍵で配置と削除を試し、登録した鍵が期待する範囲だけを操作できることを確認してください。

bootstrap手順とドメイン設定

READMEが示す安定版v0.38.27の導入例は、wgetでhttps://dokku.com/install/v0.38.27/bootstrap.shを取得し、sudo DOKKU_TAG=v0.38.27 bash bootstrap.shを実行する形です。バージョンをURLとDOKKU_TAGの両方で固定している点は、初期導入を再現するうえで大切です。実行時は、取得したスクリプトの出所、内容、ハッシュ、実行権限を組織の手続きに合わせて確認します。

インストール後は、dokku domains:set-globalでサーバーのドメインを設定し、dokku ssh-keys:addでユーザーアクセスを整えるとREADMEは説明しています。ここで決めるドメインはアプリケーションへ到達する名前解決や証明書の構成にも関係しますが、証明書管理の具体的な手順はREADMEの抜粋からは確認できません。

アップグレードと日常の保守

Dokkuはアップグレード用の公式ドキュメントへ案内しています。更新前には、現在のDokkuタグ、プラグイン、アプリケーション設定、データ保存先、SSH鍵の状態を保存します。更新後は、アプリケーションのデプロイ、ログ確認、ドメイン経由のアクセス、再起動、失敗時の戻し方を順に確認してください。

公開リポジトリの最新リリースは素材時点でv0.38.27、直前の版はv0.38.26とv0.38.25です。新しい版が存在することは更新すべき時期を自動で決める情報ではありません。プラグインや使用中のビルドパックが新しい版に対応するかを調べ、テスト用VMで結果を残してから本番へ進めます。

サポートとトラブル時の動線

READMEは、問題の調査先としてGitHub Issuesと公式ドキュメントのTroubleshootingを挙げています。コミュニティへの相談にはGliderlabs Slackの#dokkuチャンネルが案内されています。問い合わせをする前に、Dokkuの版、OS、CPUアーキテクチャ、実行したコマンド、ログ、再現条件をまとめると、原因の切り分けに必要な情報が揃います。

貢献する場合は、GitHub Issuesとトラブルシューティングガイドを確認したうえで、フォークとPull Requestを作る流れがREADMEに示されています。提出した変更がそのまま取り込まれるとは限らず、プロジェクト側は議論と改善の出発点として扱うと説明しています。これはサポート窓口の案内であり、応答時間や有償の保守契約を示すものではありません。

MITライセンスと採用前の確認

dokku/dokkuのライセンスはMITです。利用、改変、再配布の検討に使える情報ですが、配布物に含まれるプラグインや依存物のライセンスまで自動的に同じになるわけではありません。社内の法務確認では、Dokku本体、追加プラグイン、アプリケーションイメージを分けて一覧化してください。

READMEからは性能基準、可用性保証、バックアップ方式、秘密情報の保護、長期サポートの条件を確認できません。対応OSを満たす隔離VMを用意し、固定版でインストール、SSH鍵登録、ドメイン設定、アプリケーションの配置と更新を試します。失敗時にVMを作り直すだけで済む構成か、永続データをどう戻すかを確認した後で運用範囲を決めるべきです。

編集部の結論

Dokkuは、管理対象のサーバーを自分で用意し、Dockerを使ったアプリケーション配置の流れを一つのPaaSとして扱いたい人に向きます。対応OSとCPUアーキテクチャ、sudo権限、SSH鍵、ドメインの割り当てを先に揃えてください。READMEが示すbootstrap手順は初期導入の入口であり、バックアップ、ネットワーク公開、アプリケーションごとの復旧、アップグレード結果までを保証するものではありません。固定版で試し、運用者が戻せる手順を確認してから利用範囲を決めるのが適切です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes