コード管理と自動化を、
VPSで小さく始める
GitLabやJenkinsをVPSに置くと、リポジトリ、課題管理、テスト、デプロイの流れを一つの環境で試せます。
小規模チームの導入順
- Gitリポジトリとユーザー権限を設定
- ブランチ保護とレビュー手順を決める
- 軽いテストだけCIへ移す
- 成果物の保存期間と容量を決める
- 本番デプロイは承認制にする
見落としやすいコスト
リポジトリとCI成果物は時間とともに増えます。ディスク容量、バックアップ時間、CI実行時のCPU・メモリを監視し、不要な成果物を定期削除します。
VPS.orgの公式アプリ一覧にはGitLabとJenkinsが掲載されています。チーム人数とビルド内容に応じてプランを選びましょう。
DevOps VPS よくある質問（FAQ）
Q. GitLabをVPSで動かすのに最低どれくらいのスペックが必要ですか？
GitLab公式の推奨は最低4GBのRAMです。2GBでも起動はできますが、処理が重くなりタイムアウトが発生しやすいため、VPSは4GB以上を選ぶことを推奨します。ストレージはリポジトリが増えると急速に消費するため、SSD 50GB以上を目安にしてください。
Q. CIパイプラインの実行中にVPSのCPUが100%になります。どう対処すればいいですか？
GitLab RunnerやJenkinsのBuild Executorを、メインのGitLabサーバーとは別のVPSまたはコンテナで動かす構成にすることで解決できます。ビルド専用のRunnerサーバーを1台追加し、ジョブをオフロードするのが最もシンプルな対処法です。GitLabの場合は「Executor: shell」から「Executor: docker」に変更し、コンテナ単位でCPU制限をかけることも有効です。
Q. VPS上でDockerを使ってCI/CDを組む場合、コンテナのネットワーク設定で気をつけることはありますか？
主に3点あります。①ポート公開の最小化：外部に公開するポートは必要なものだけに絞り、GitLabのHTTP/HTTPSとSSH以外はファイアウォールでブロックする。②コンテナ間通信はDockerネットワーク内で完結させ、外部公開しない。③GitLab Runnerが別コンテナのDockerを呼び出す「Docker in Docker（DinD）」構成は特権モードが必要なため、セキュリティリスクを理解した上で使用する。
Q. JenkinsとGitLabを同じVPSに入れるのはアリですか？
小規模プロジェクト（開発者2〜3名、1日10ビルド以下）であればRAM 8GB程度のVPSで共存できます。ただし、GitLabとJenkinsはどちらもメモリを多く消費するため、ビルドが集中する時間帯にメモリ不足が起きやすい点に注意が必要です。本番運用では分離を推奨します。
Q. CI/CDパイプラインでデプロイを自動化するとき、VPSの秘密情報（APIキー・SSHキー）はどう管理すればいいですか？
GitLabの場合は「CI/CD Variables」（設定 → CI/CD → Variables）に秘密情報を登録し、パイプライン内で環境変数として参照します。ファイルに直書きしたりリポジトリにコミットしたりしてはいけません。Jenkinsの場合は「Credentials Manager」を使います。さらにセキュリティを高めたい場合はHashiCorp Vaultとの連携も有効です。
Q. GitLabのバックアップはどうすればいいですか？
GitLabには組み込みのバックアップ機能があります。sudo gitlab-backup create コマンドでバックアップファイルを生成できます。これをcronで定期実行し、生成されたtarファイルをS3互換ストレージやリモートサーバーに転送するスクリプトを組み合わせるのが基本構成です。GitLabの設定ファイル（/etc/gitlab/gitlab.rb）は別途バックアップする必要があります。