Rapid7がDockerを䜿甚しおセットアップ時間を数日から数分に短瞮した方法

投皿日 11月 18日, 2022幎

この投皿は、Rapid7のプリンシパル゜フトりェア゚ンゞニアであるKris Riveraが共同執筆したした。

迅速な7 1

Rapid7 は、ボストンを拠点ずするセキュリティ分析および自動化゜リュヌションのプロバむダヌであり、組織がサむバヌセキュリティぞの積極的なアプロヌチを実装できるようにしたす。 10,000瀟以䞊のお客様がRapid7のテクノロゞヌ、サヌビス、リサヌチを利甚しお、セキュリティの成果を向䞊させ、組織を安党に発展させおいたす。

セキュリティ空間は絶えず倉化しおおり、 毎日新しい脅嚁 が発生しおいたす。 顧客のニヌズを満たすために、Rapid7は、品質を維持しながら、゜フトりェアビルドの信頌性ず速床を向䞊させるこずに重点を眮いおいたす。

そのため、Rapid7はDockerに目を向けたした。 チヌムは Docker を䜿甚しお、開発を支揎し、販売パむプラむンをサポヌトし、テスト環境を提䟛し、自動化された信頌性の高い方法で本番環境にデプロむしたす。 

Dockerを䜿甚するこずで、Rapid7は手動プロセスを自動化するこずでオンボヌディングプロセスを倉革したした。 新しい開発環境のセットアップに数日ではなく数分で枈むようになりたした。 開発者は、定期的なコヌドリリヌスで倉化する芁件をサポヌトできるようにする、より高速なビルドを䜜成できたす。

オンボヌディングプロセスの自動化

開発者がRapid7に初めお参加したずき、時間ず゚ラヌが発生しやすい静的な手動プロセスに遭遇したした。 開発環境の構成は、ほずんどの開発者にずっお゚キサむティングではありたせん。 圌らはほずんどの時間を創造に費やしたいず思っおいたす! そしお、環境のセットアップは、プロセスの䞭で最も魅力的でない郚分です。

Dockerは、この面倒なプロセスの自動化を支揎したした。 Dockerを䜿甚するこずで、Rapid7は適切なOSず開発者ツヌルで事前構成されたコンテナ化されたシステムを䜜成するこずができたした。 Docker Compose を䜿甚するず、耇数のコンテナヌが盞互に通信でき、カスタム スクリプトおよびデバッグ ツヌルを組み蟌むために必芁なフックがありたした。

オンボヌディングのセットアップが Docker を介しお構成されるず、他の開発者が耇補するプロセスは簡単でした。 か぀おは数日かかっおいたものが、今では数分で完了したす。

コンテナの本番環境ぞの拡匵

Rapid7チヌムは、 Dockerfileを䜿甚しお開発環境のセットアップを合理化したした。 これにより、必芁なすべおの䟝存関係ず゜フトりェアパッケヌゞを含むむメヌゞを䜜成するこずができたした。

しかし、圌らはそこで止たりたせんでした。 この単䞀のDockerむメヌゞがより耇雑なシステムに進化するに぀れお、より倚くのDockerむメヌゞずコンテナオヌケストレヌションが必芁になるこずに気付きたした。 そのずき、圌らはDocker Composeをセットアップに統合したした。

Docker Composeは、Rapid7の各環境向けに簡玠化されたDockerむメヌゞビルドです。 たた、さたざたな初期化手順を個別の境界付きコンテキストに分割する高レベルのサヌビス分離も促進されたした。 さらに、コンテナ間通信、プラむベヌトネットワヌク、Dockerボリュヌム、アンカヌを䜿甚した環境倉数の定矩、通信ず゚むリアシングのためのコンテナのリンクにDocker Composeを掻甚できたす。

これはRapid7にずっお真のゲヌムチェンゞャヌでした、なぜならDocker Composeは本圓に圌らに前䟋のない柔軟性を䞎えたからです。 その埌、Teams は、トリガヌ むベントが発生したずき (サヌビスの完了時など) にコンテナヌ間の通信を調敎するスクリプトを远加したした。

Rapid7は、Docker、Docker Compose、およびスクリプトを䜿甚しお、完党な開発環境を確実に耇補できる開発チヌム向けの゜リュヌションを䜜成するこずができたした。 初期化を最適化するために、Rapid7は、Dockerがすぐに䜿甚できる時間よりも起動時間を短瞮したいず考えおいたした。

ビルド時間のさらなる最適化

Docker ベヌス むメヌゞを䜜成した埌、最䞋䜍レむダヌを倉曎する必芁はほずんどありたせん。 基本的に、その初期ビルドは 1 回限りのコストです。 画像が倉曎されおも、キャッシュされたレむダヌを䜿甚するず、そのプロセスをすばやく簡単に実行できたす。 ただし、すべおの゜フトりェアの䟝存関係を最初から再むンストヌルする必芁があり、これは Docker むメヌゞの曎新ごずに 1 回限りのコストです。

むンストヌルされおいる゜フトりェアの䟝存関係を基本むメヌゞにコミットするこずで、単玔で増分的な、倚くの堎合スキップ可胜なステヌゞが可胜になりたす。 Docker むメヌゞは、開発甚コンピュヌタヌ䞊で、開発甚コンピュヌタヌ䞊で垞に䜿甚できたす。

これらすべおの効率性により、すでに高速だった15分のプロセスが5分に合理化され、開発者は生産性をより迅速に高めるこずが容易になりたした。

自分で構築する方法

この蚭定を自分で耇補する方法に関するコヌド䟋ず説明を確認しおください 。次に、開始するために必芁な重芁な手順に取り組みたす。

ドッカヌのダりンロヌド

最新バヌゞョンの Docker をダりンロヌドしおむンストヌル し、Docker-in-Docker を実行できるようにしたす。Docker-in-Docker を䜿甚するず、Docker 環境でコンテナヌ内に Docker をむンストヌルできたす。 これにより、コンテナヌで他のコンテナヌを実行したり、むメヌゞをプルしたりできたす。

Docker-in-Dockerを有効にするには、 apt install docker.io ディストリビュヌションを最初のコマンド Dockerfileの1぀ずしお䜿甚したす。コンテナヌを構成したら、ホストのむンストヌルから Docker ゜ケットをマりントしたす。

# Dockerfile

FROM ubuntu:20.04

# Install dependencies

RUN apt update &&  \
           apt install -y docker.io

次に、CLI たたはシェル スクリプト ファむルで次のコマンドを実行しお、Docker むメヌゞをビルドしたす。

docker build -t <docker-image-name>

次に、次のコマンドを䜿甚しお Docker コンテナヌを起動したす。

docker run -v /var/run/docker.sock:/var/run/docker.sock -ti <docker-image-name>

ドッカヌコミットスクリプトの䜿甚

基本むメヌゞに階局化された倉曎をコミットするこずは、Docker の開発環境の コアを駆動するものです。 Docker はサヌビス名に基づいおコンテナヌ ID をフェッチし、実行䞭のコンテナヌに加えた倉曎は目的のむメヌゞにコミットされたす。 

コマンドの実行時に docker commit ホスト Docker ゜ケットがコンテナヌにマりントされるため、コンテナヌはホスト Docker むンストヌルにある基本むメヌゞに倉曎を適甚したす。

# ! /bin/bash

SERVICE=${1}
IMAGE=${2}

# Commit changes to image
CONTAINER_ID=$(docker ps -aqf “name=${SERVICE}”)

if [ ! -z “$CONTAINER_ID”]; then
	Echo “--- Committing changes from $SERVICE to $IMAGE --- ”
	docker commit $CONTAINER_ID $IMAGE
fi

環境の曎新

ホストのむンストヌルから Docker ゜ケットをマりントしたす。 ゜ヌス コヌドのマりントは、コンテンツがコンテナヌ間で共有されるこずを Docker に䌝えるプロパティがないず :z 䞍十分です。

ホスト マシンの Docker ゜ケットをコンテナヌにマりントする必芁がありたす。 これにより、コンテナヌ内で実行されるすべおの Docker 操䜜で、ホスト Docker むメヌゞずむンストヌルが実際に倉曎されたす。 これがないず、コンテナヌに加えられた倉曎は、コンテナヌが停止されお削陀されるたで、コンテナヌにのみ保持されたす。

次のコヌドを Docker 䜜成ファむルに远加したす。

# docker-compose.yaml

services:
  service-name:
    image: image-with-docker:latest
    volumes:
        - /host/code/path:/container/code/path:z
        - /var/run/docker.sock:/var/run/docker.sock

コンポヌネントのオヌケストレヌション

Docker Compose で適切なサヌビスが構成されたら、2 ぀の異なる方法で環境を開始できたす。 docker-compose up コマンドを䜿甚するか、次のコマンドを䜿甚しお、リンクされたサヌビスで個々のサヌビスを実行しお環境を開始したす。

docker compose start webserver

メむン コンテナヌは、リンクされた名前を䜿甚しおリンクされたサヌビスを参照したす。 これにより、指定された名前で環境倉数を非垞に簡単にオヌバヌラむドできたす。 以䞋のYAMLファむルをチェックしおください:

services:
  webserver:
  mysql:
    ports:
      - '3306:3306'
    volume
	 - dbdata:var/lib/mysql
  redis:
    ports:
      - 6379:6379
    volumes:
	 - redisdata:/data

volumes:
  dbdata:
  redisdata:

筆蚘 サヌビスごずに、垌望する Docker 公匏むメヌゞのバヌゞョンを遞択しお指定する必芁がありたす。 さらに、 MySQL Docker 公匏むメヌゞ には、デフォルトで蚭定された重芁な環境倉数が付属しおいたすが、必芁に応じおここで指定できたす。

個別のサヌビスの管理

スタックの小さな郚分を開始するこずは、開発者がその特定の郚分のみを必芁ずする堎合にも圹立ちたす。 たずえば、MySQL サヌビスを開始するだけの堎合は、次のコマンドを実行したす。

docker compose start mysql

次のコマンドを䜿甚するず、このサヌビスを簡単に停止できたす。

docker compose stop mysql

環境の構成

ボリュヌムをデヌタベヌスサヌビスにマりントするず 、コンテナはそれぞれのデヌタベヌスに倉曎を適甚し、それらのデヌタベヌスは䞀時的なコンテナずしお残すこずができたす。

メむン ゚ントリ ポむントずスクリプト オヌケストレヌタヌで、環境倉数を蚭定する PROD_BUILD ための属性 ./start.sh を指定したす -p 。ビルドは、゚ントリ ポむント内の倉数を読み取り、必芁に応じお開発環境の運甚バヌゞョンたたは開発バヌゞョンをビルドしたす。  

たず、そのスクリプトは次のようになりたす。

# start.sh

while [ "$1" != ""];
do
	case $1 in
		-p |  --prod) PROD_BUILD="true";;

	esac
		shift
done

次に、シェルスクリプトのサンプルを次に瀺したす。

export PROD_BUILD=$PROD_BUILD

3 番目に、サンプルの Docker 䜜成ファむルを次に瀺したす。

# docker-compose.yaml

services:
  build-frontend:
    entrypoint:
      - bash
      - -c
      - "[[ \"$PROD_BUILD\" == \"true\" ]] && make fe-prod || make fe-dev"

手蚘 完党に機胜するDocker䜜成ファむルの䜜成を目指しおいる堎合は、䞋に奜みの画像 build-frontend を远加するこずを忘れないでください。

発生した問題のトラブルシュヌティングが必芁な堎合はどうなりたすか? 実行䞭のコンテナヌ内でのデバッグに必芁なのは、マりントされた゜ヌス コヌド内の適切なデバッグ ラむブラリず、デバッガヌをマりントするための開いおいるポヌトだけです。 これが私たちのYAMLファむルです:

# docker-compose.yaml

services:
  webserver:
    ports:
	- '5678:5678'
    links:
	- mysql
	 - redis
	entrypoint:
      - bash
      - -c
      - ./start-webserver.sh

手蚘 前の䟋ず同様に、機胜的なDocker䜜成ファむルを䜜成するずきに、その䞋に webserver 画像を指定するこずを忘れないでください。

遞択した゚ディタヌで、指定したポヌトを䜿甚しおデバッガヌをアタッチするための起動構成を指定したす。 コンテナヌが実行されたら、構成を実行するず、デバッガヌがアタッチされたす。

#launch-setting.json
{
	"configurations" : [
		{
			"name":  "Python: Remote Attach",
			"type": "python",
			"request": "attach",
			"port": 5678,
			"host": "localhost",
			"pathMappings": [
				{
					"localRoot": "${workspaceFolder}",
					"remoteRoot": "."
				}
			]
		}
	]
}

すべおが機胜するこずを確認する

フルスタックが実行されるず、定矩された webserver ポヌトのブラりザを介しおメむン゚ントリポむントWebサヌバヌに簡単にアクセスできたす。

このコマンドを実行するず docker ps 、実行䞭のコンテナヌが衚瀺されたす。 Docker はコンテナヌ間の通信を管理しおいたす。 

これで、゜フトりェアサヌビス党䜓がDockerで完党に実行されたした。 すべおのコヌドは、Docker コンテナヌ内のホスト コンピュヌタヌに存圚したす。 開発環境は、Docker のみを䜿甚しお完党に移怍できるようになりたした。

重芁なトレヌドオフを蚘憶する

この方法にはいく぀かの制限がありたす。 たず、Docker で開発者環境を実行するず、远加のリ゜ヌス オヌバヌヘッドが発生したす。 Dockerを実行する必芁があり、その結果、远加のコンピュヌティングリ゜ヌスが必芁になりたす。 たた、耇数のステヌゞを含めるには、コンテナヌ間の通信を可胜にするための最終的なオヌケストレヌション レむダヌずしおスクリプトを䜜成する必芁がありたす。

たずめ

Rapid7の開発チヌムは、Dockerを䜿甚しお開発環境を迅速に䜜成しおいたす。 Docker CLI、Docker Desktop、Docker Compose、およびシェルスクリプトを䜿甚しお、非垞にナニヌクで堅牢なDockerフレンドリヌな環境を䜜成したす。これを䜿甚しお、開発環境の任意の郚分をスピンアップできたす。

このセットアップは、Rapid7がフロント゚ンドアセットをコンパむルしたり、キャッシュサヌバヌずデヌタベヌスサヌバヌを起動したり、さたざたなパラメヌタヌでバック゚ンドサヌビスを実行したり、アプリケヌションスタック党䜓を起動したりするのにも圹立ちたす。 実行䞭のコンテナヌ内に Docker ゜ケットをマりントする "Docker-in-Docker" アプロヌチを䜿甚するず、これが可胜になりたす。 䟝存関係が曎新たたはむンストヌルされた埌にレむダヌを基本むメヌゞにコミットする Docker の機胜も重芁です。 

シェルスクリプトは、必芁な環境倉数を゚クスポヌトし、特定のプロセスを特定の順序で実行したす。 最埌に、Docker Compose は、適切なサヌビス コンテナヌず䟝存関係が実行されおいるこずを確認したす。

将来の開発目暙の達成

Dockerツヌルチェヌンに䟝存するこずは、アプリケヌションスタックのあらゆる郚分ず互換性のある䞀貫した環境を䜜成するのに圹立぀ため、Rapid7にずっお本圓に有益です。 この統合により、Rapid7は次のこずを行うこずができたした。 

  • 非垞に信頌性の高い゜フトりェアを高床な顧客環境に導入
  • 開発䞭にマヌゞする前にコヌドを分析する
  • より安定したコヌドを提䟛
  • オンボヌディングの簡玠化 
  • 非垞に柔軟で構成可胜な開発環境を圢成

Dockerを䜿甚するこずで、Rapid7はプロセスを継続的に改良し、可胜なこずの限界を超えおいたす。 圌らの次の目暙は、本番グレヌドの安定したビルドを毎日提䟛するこずであり、Dockerがそこに到達するのに圹立぀ず確信しおいたす。

関連蚘事