自分のアプリケーションに適切な Docker イメージを作成しているかどうかについて疑問を抱いたことがない人はいないでしょうか?そうですね、私はこの質問を何度か受けましたが、ほとんどの場合、自分のやり方が正しいのか間違っているのかわかりませんでした。
この記事では、Go アプリケーション用に効率的で最適化された Docker イメージを作成するための高度な実践方法について説明します。アルパインベースイメージとスクラッチベースイメージの使用など、さまざまなアプローチを比較し、それぞれの利点についてコードを使用して説明します。例とパフォーマンス分析。
まず、コンテナ化された Go アプリケーションの典型的なプロジェクト構造を確立しましょう。
例として、私は URL 短縮アプリケーションである次のアプリケーションを使用しています:
url_shortener ├── cmd │ └── main.go ├── internal │ ├── monitoring │ │ └── prometheus.go │ ├── server │ │ └── server.go │ └── shortener │ ├── model.go │ ├── repository.go │ ├── service.go │ └── service_test.go ├── pkg │ ├── api │ │ └── shortener │ │ ├── handler.go │ │ └── handler_integration_test.go │ └── utils │ └── base62 │ ├── hash.go │ └── hash_test.go ├── Dockerfile ├── Dockerfile.alpine ├── Dockerfile.golang ├── README.md ├── compose.yml ├── go.mod ├── go.sum └── prometheus.yml
ほとんどの人が知っていることですが、運用環境で「完全な」イメージを実行する必要はないということです。たとえば、すべてのパッケージ、ソース、拡張機能、および言語の SDK を備えた Ubuntu です。 SDK を使用してシステム内でアプリをビルドし、そのビルドのみを実行する、より小さく最適化されたイメージにそのビルドをコピーするだけです。そこでマルチステージが登場します。
Dockerfile では、それぞれが FROM ステートメントで始まる複数のビルド ステージを定義できます。最初のステージは、コードのコンパイル、依存関係のインストール、テストの実行などに使用できます。後続の段階では、必要なアーティファクト (コンパイルされたバイナリなど) のみを最終イメージにコピーし、アプリケーションの実行に必要でないものはすべて破棄できます。
# syntax=docker/dockerfile:1 # Build stage FROM golang:1.22-alpine AS builder WORKDIR /app COPY . . RUN go mod download RUN go build -o url-shortener ./cmd # Final stage FROM alpine:latest WORKDIR /app COPY --from=builder /app/url-shortener . CMD ["./url-shortener"]
くそー、ラファ、でも「この 2 枚の画像」で何をしているの?まず、イメージをビルダーとして使用し、ここでアプリケーションの実行可能ファイルを作成します。
最初のステージ (ビルドステージ):
それでは、最初のステップで生成したこの実行可能ファイルを実行する小さなイメージを使用します。
第 2 ステージ (最終ステージ):
実際に何が起こっているのかを確認したい場合は、Docker Desktop 内でイメージの階層を分析することができます。内部では彼が何を使っているかを見ることができます:
これで、生成したばかりのこの画像のサイズも分析できます。この場合、url-shortener:alpine は約 30mb でした:
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE url-shortener alpine aa99d6a2c028 3 minutes ago 29.9MB
Alpine は、最小限で安全かつ軽量な Linux ディストリビューションであり、その効率性とシンプルさによりコンテナ環境で広く使用されています。他の重い Linux ディストリビューションのようなオーバーヘッドを発生させずに、スケーラブルなアプリケーションを構築するための強固な基盤を提供します。
アプリで Alpine を使用する利点のいくつかは、主に次の 3 つの柱に関連しています:
わかりましたが、同じ SDK バージョン (この場合は golang:1.22-alpine) を使用した場合はどうなるでしょうか。私のアプリケーションのサイズはどれくらいですか?
REPOSITORY TAG IMAGE ID CREATED SIZE url-shortener golang-alpine d615d75c3aff 25 minutes ago 251MB
そうですね、この場合、画像のサイズは最大 250 MB になりました。アルパインと比較すると、純粋に最大 30 MB になりましたが、これはすでに大きな違いです。そしてそれをさらに改善することはできるのでしょうか？
答えは「はい」です。詳細を見ていきましょう
Scratch は、Docker の特別で非常にシンプルなイメージです。実際、これは使用できる最も単純で空の基本イメージです。これには、オペレーティング システム、ライブラリ、ツールなど、まったく何も含まれていません。文字通り空のコンテナです。
Essa abordagem minimalista traz benefícios significativos, especialmente em termos de segurança. Ao usar Scratch, você minimiza drasticamente a superfície de ataque, já que não há pacotes ou ferramentas adicionais que possam introduzir vulnerabilidades. Seu contêiner contém apenas o essencial para a execução do aplicativo, garantindo um ambiente imutável e previsível em qualquer situação.
# syntax=docker/dockerfile:1 # Build stage FROM golang:1.22-alpine AS builder WORKDIR /app COPY . . RUN go mod download RUN go build -o url-shortener ./cmd # Final stage with Scratch FROM scratch WORKDIR /app COPY --from=builder /app/url-shortener . CMD ["./url-shortener"]
E o resultado após criar as 3 imagens, nosso ranking de menor imagem ficou assim:
O Scratch conseguiu baixar mais alguns megas no tamanho final de nossa aplicação. Isso impacta no tamanho de arquivos transferidos pela rede, hoje algumas empresas cobram pela banda que trafegamos dentro dos servidores, e também pode influenciar em nosso Horizontal Scaling da aplicação.
Deixei os 3 Dockerfiles dentro do repositório do github caso você queira testar em seu próprio pc ?
A resposta mais tranquila para essa é "quase sempre", uma dica de cara é: ele vai muito bem com linguagens como Go, Rust, ou C/C++. Mas qui estão alguns pontos para levar em consideração na hora de escolher se deve ou não usar o scratch:
Usar o cache do Docker para otimizar o tempo de build é uma técnica essencial para evitar recompilar ou baixar dependências desnecessariamente em cada build. O Docker armazena em cache as camadas de cada etapa do Dockerfile, reutilizando-as sempre que possível.
Em projetos Go, baixar dependências com go mod download pode ser um processo demorado, especialmente se houver muitas dependências. Se você recompilar todas as dependências em cada build, isso aumenta significativamente o tempo de build.
Ao copiar apenas os arquivos go.mod e go.sum em uma etapa separada antes de copiar o código-fonte completo, você permite que o Docker use o cache dessa etapa se os arquivos go.mod e go.sum não tiverem mudado. Veja como fica nosso Docker file com as mudanças:
# syntax=docker/dockerfile:1 # Build stage FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN go build -o url-shortener ./cmd # Final stage FROM scratch WORKDIR /app COPY --from=builder /app/url-shortener . CMD ["./url-shortener"]
Só de fazer esta pequena mudança já ganhamos dois pontos bem interessantes quando se trata de desenvolvimento de software, que são:
Menor tempo de build: Se não houver alterações nos arquivos go.mod e go.sum, o Docker reutiliza o cache, evitando o download das dependências e economizando tempo.
Eficiência no CI/CD: Em pipelines de integração contínua, essa técnica reduz o tempo de execução dos pipelines, aumentando a eficiência do desenvolvimento e entrega.
Então bora usar isso a nosso favor no dia-a-dia :)
Docker Scout é uma ferramenta da Docker integrada ao Docker Desktop que analisa suas imagens para identificar vulnerabilidades de segurança. Ele fornece insights sobre as dependências presentes em suas imagens e alerta sobre possíveis problemas, permitindo que você tome medidas corretivas antes de implantar suas aplicações.
Por que é importante? Manter suas imagens Docker seguras é fundamental para proteger suas aplicações contra ataques e exploração de vulnerabilidades. O Docker Scout automatiza o processo de análise, tornando mais fácil manter suas imagens seguras e atualizadas.
O Scout funciona praticamente com 2 passos, ele examina a imagem Docker, mapeia todas as dependências incluídas na imagem e verifica essas dependências em uma base de dados de vulnerabilidades conhecidas. Por fim, classifica as vulnerabilidades encontradas por severidade e fornece recomendações para corrigir ou mitigar os problemas.
このようにして、イメージが運用環境にデプロイされる前に脆弱性を特定して修正する予防的な予防策が得られ、セキュリティ上の悪用の可能性から保護するのに役立ち、運用効率も向上します。これはどういう意味ですか?脆弱性分析を自動化できるため、DevOps チームやセキュリティ チームは手動調査ではなく是正措置に集中できるようになります。
これまで検討してきた実践により、マルチステージ ビルドなどの手法を使用して Go アプリケーション用の Docker イメージを作成し、イメージ サイズを削減し、アルパインやスクラッチなどのベース イメージを選択してセキュリティを強化し、また、Docker Scout を使用して脆弱性を監視することで、アプリケーションが効率的かつ安全に実行されていることを確認できます。
これらの実践は、技術的なパフォーマンスを向上させるだけでなく、日常生活や会社に直接的な利益をもたらし、時間とリソースを節約します。
次回 Docker イメージを構築するときは、これらの戦略を念頭に置いてください。それらを適用して結果を観察してください。 ?
以上がGo + Docker: Golang アプリケーションに最適な Docker イメージを作成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
