Images Docker pour Go (Golang) Images Docker petites et plus rapides et sécurité

Pendant le week-end, j'ai fait des recherches sur les images Docker spécifiquement destinées à être utilisées avec les applications Go (Golang). par conséquent, j'ai pensé à partager les découvertes intéressantes, car cela pourrait être utile à quelqu'un qui explore la même chose pour ses travaux de projet technologique.

Ici, je vais élaborer différentes manières de créer une image pour Golang et également souligner certaines des considérations de sécurité que nous devons prendre en compte lors de la sélection d'une image.

Pour cet exercice, j'utilisais une simple API Rest développée avec Go (Golang) à l'aide du framework Gin.

Le framework Gin est un framework Web populaire pour Go (Golang) conçu pour être rapide, facile à utiliser et très efficace.
 
Voici un bref résumé de ses principales caractéristiques et caractéristiques ;

Principales fonctionnalités

• Performance : Le Gin est connu pour sa haute performance. Il s'agit de l'un des frameworks Web Go les plus rapides, offrant une surcharge minimale par rapport aux autres frameworks.

• Routeur HTTP rapide : Gin utilise un routeur HTTP rapide et prend en charge le routage avec des méthodes telles que GET, POST, PUT, DELETE, etc. Il prend également en charge le middleware et le regroupement de routes.

• Support middleware : Gin fournit un moyen d'utiliser un middleware pour gérer des tâches telles que la journalisation, l'authentification et d'autres pré- ou post-traitements de requêtes.

• Validation JSON : Le framework offre une prise en charge intégrée de la validation JSON et lie les données de requête aux structures Go, ce qui facilite le travail avec les charges utiles JSON.

• Gestion des erreurs : Gin a une manière structurée de gérer les erreurs et fournit un système central de gestion des erreurs, vous permettant de gérer les erreurs avec élégance.

• Rendu de modèles : Bien que Gin soit principalement conçu pour le développement d'API, il prend en charge le rendu de modèles HTML si nécessaire.

• Traitement des demandes : Prend en charge différentes méthodes de traitement des demandes, notamment les données de formulaire, les charges utiles JSON et les paramètres d'URL.

• Débogage intégré : Gin fournit des messages d'erreur détaillés et des informations de débogage qui peuvent être utiles pendant le développement.

Composants clés

• Routeur : Le composant principal qui gère le routage des requêtes HTTP vers les gestionnaires appropriés.

• Contexte : Une structure qui transporte les données de requête et de réponse, et
  fournit des méthodes pour les gérer. Il est largement utilisé par les gestionnaires.

• Moteur : L'instance principale de l'application Gin, qui est configurée avec des routes, un middleware et d'autres paramètres.

• Middleware : Fonctions qui s'exécutent pendant le cycle de vie de la demande, vous permettant d'effectuer des tâches telles que la journalisation, l'authentification, etc.

Assez parlé de Gin Framework :) passons maintenant au sujet principal et parlons des tests effectués.

Test 1 (version Docker standard)

Dans ce test, nous utiliserons une image de base officielle Standard/Regular Go

# Official Go Base Image
FROM golang:1.21.0

# Create The Application Working Directory
WORKDIR /app

# Copy and Download Dependencies
COPY go.mod go.sum .
RUN go mod download

# Copy Source and Build The Application
COPY . .
RUN go build -o main .

# Expose The Port
EXPOSE 8081
CMD ["./main"]

Taille de l'image

---

Test 2 (construction de Docker en plusieurs étapes avec Alpine Image)

Dans ce test, nous utiliserons la version Alpine de Go Base Image qui est légèrement plus légère

# Official Go Apline Base Image
FROM golang:1.21.0-alpine as builder

# Create The Application Directory
WORKDIR /app

# Copy and Download Dependencies
COPY go.mod go.sum .
RUN go mod download

# Copy The Application Source & Build
COPY . .
RUN go build -o main .

# Final Image Creation Stage
FROM alpine:3.19

WORKDIR /root/

# Copy The Built Binary
COPY --from=builder /app/main .

# Expose the port
EXPOSE 8081
CMD ["./main"]

Taille de l'image

Ici, vous pouvez voir qu'avec une construction en plusieurs étapes, la taille des images est considérablement réduite.

---

Test 3 (construction sans distribution)

Dans ce test, nous utiliserons une image de base Google Distroless Go. Les images sans distribution sont connues pour être légères et sécurisées et ne contiennent que le minimum de fichiers requis. En cela, ces shells de débogage et packages inutiles ont été supprimés. par conséquent, vous sacrifiez la flexibilité d'avoir un gestionnaire de paquets et un shell.

# Build Stage
FROM golang:1.21.0 as builder

# Set The Application Directory
WORKDIR /app

# Copy and Download Dependencies
COPY go.mod go.sum .
RUN go mod download

# Copy The Application Source and Build the application
COPY . .
RUN CGO_ENABLED=0 go build -o main .

# Final Image Creation Stage
FROM gcr.io/distroless/static-debian12

# Copy the built binary
COPY --from=builder /app/main /
CMD ["/main"]

Taille de l'image

---

CGO_ENABLED=0 : Il s'agit d'un paramètre de variable d'environnement qui désactive CGO (C-Go). CGO est une fonctionnalité de Go qui permet aux packages Go d'appeler du code C. Le réglage de CGO_ENABLED=0 garantit que la construction ne dépend d'aucune bibliothèque C, produisant un binaire entièrement statique. Ceci est utile pour créer des binaires Go légers et portables qui peuvent s'exécuter sur n'importe quel système sans nécessiter de dépendances supplémentaires.

En résumé, RUN CGO_ENABLED=0 go build -o main . signifie que Docker exécutera une commande pour créer une application Go dans le répertoire courant, produisant un binaire statique nommé main qui ne dépendent de toutes les bibliothèques C.

Résumé

Taille de l'image

Même si les images Distroless sont légèrement plus grandes que les images alpines, la menace/vulnérabilité de sécurité pourrait vous obliger à choisir Distroless !. Pensez donc à tous ces faits et choisissez celui qui correspond à vos exigences

Alpine with Multi-Stage Builds est un bon choix si vous avez besoin de plus de contrôle sur le processus de construction, et si les problèmes de compatibilité avec musl libc ne sont pas une préoccupation. Elle offre de la flexibilité et est plus petite que de nombreuses autres images de base, mais comprend toujours plus de composants que les images Distroless, ce qui peut entraîner des vulnérabilités/menaces potentielles en matière de sécurité.

Les

Images Google Distroless sont idéales pour maximiser la sécurité et minimiser la surface d'attaque. Ils fournissent un environnement d'exécution très minimal, ce qui peut être bénéfique pour les systèmes de production où la sécurité est une priorité. Cependant, vous sacrifiez la flexibilité d'avoir un gestionnaire de paquets et un shell.

Recommandation:

Utilisez Alpine si vous avez besoin de flexibilité et de contrôle sur l'environnement de construction, et si les problèmes de compatibilité avec musl libc ne sont pas un problème.

Utilisez Google Distroless si la sécurité et la réduction de la surface d'attaque sont vos principales priorités, et vous pouvez vous assurer que toutes les dépendances de votre application sont correctement regroupées.

J'espère que c'était intéressant et merci pour votre temps !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!