Introduction
Votre équipe prépare la livraison d’une petite application HTTP. Empaquetez le code fourni dans une image de conteneur, stockez-la dans Amazon Elastic Container Registry (ECR) et démontrez que la version exacte démarre et répond à une requête. Préservez le dépôt de référence, puis supprimez vos ressources.
Terminez d’abord AWS Foundations et les bases des stratégies d’identité IAM. Les concepts Docker sont expliqués ici ; vous n’avez ni à écrire l’application ni à disposer d’un compte AWS personnel. Cette VM indépendante fournit AWS CLI configurée, Docker, un Dockerfile et le code source. Utilisez AWS View, en haut, pour observer les dépôts et tester l’application, et Terminal, en bas, pour les commandes. Les deux lisent le même état des ressources.
Lien avec la certification
| Certification | Tâche de l’examen | Pratique |
|---|---|---|
| Developer – Associate (DVA-C02) | Tâche 3.1, compétence 3.1.1 | Empaqueter le code et l’environnement d’exécution d’une application dans une image de conteneur à déployer. |
Vue d’ensemble du laboratoire

Créer un dépôt d’images immuable
Dans cette étape, créez le dépôt destiné à stocker votre version applicative.
Une image regroupe les fichiers et leur environnement d’exécution. Un conteneur est une instance en cours d’exécution. Un registre stocke et distribue les images ; un dépôt ECR regroupe celles d’une application. Stocker l’image ne démarre pas l’application.
Allez dans l’espace préparé et examinez le Dockerfile. cat affiche un fichier texte :
cd /home/labex/project
cat application/Dockerfile
FROM choisit l’image Python de base, COPY ajoute l’application, USER choisit un utilisateur non privilégié et CMD définit le démarrage. La référence de base sha256 fixe son contenu ; elle n’identifie pas votre nouvelle image.
Créez ct-demo. Une étiquette est un nom lisible, comme release-1. IMMUTABLE empêche de remplacer une étiquette existante par un contenu différent et rend les noms de versions fiables :
aws ecr create-repository \
--repository-name ct-demo \
--image-tag-mutability IMMUTABLE
La réponse contient repositoryUri, l’adresse utilisée par Docker, et imageTagMutability: IMMUTABLE. Enregistrez l’URI dans une variable du shell. $(...) capture la sortie, --query sélectionne un champ et --output text retire les guillemets JSON :
REPOSITORY_URI=$(aws ecr describe-repositories \
--repository-names ct-demo \
--query 'repositories[0].repositoryUri' \
--output text)
echo "$REPOSITORY_URI"
Gardez cette session Terminal ouverte pour conserver les variables. Dans AWS View, en haut, ct-demo apparaît avec zéro image à côté de ct-reference. Ce dépôt de référence appartient à une autre application et ne doit pas être supprimé.
Construire et publier la version
Dans cette étape, construisez l’application fournie et envoyez son image vers ECR.
Docker doit s’authentifier au registre avant l’envoi. Son adresse est la partie de l’URI avant la première barre oblique. ${REPOSITORY_URI%%/*} enlève cette barre et tout ce qui suit :
REGISTRY=${REPOSITORY_URI%%/*}
echo "$REGISTRY"
Demandez à AWS CLI un mot de passe ECR temporaire et transmettez-le directement à Docker. Le tube | relie les commandes ; --password-stdin évite d’exposer le mot de passe dans les arguments ou la sortie Terminal. Ne l’affichez pas et ne l’enregistrez pas vous-même :
aws ecr get-login-password | docker login \
--username AWS \
--password-stdin "$REGISTRY"
Docker affiche Login Succeeded. Seules les opérations permises à votre identité sont autorisées, pas l’accès à tous les dépôts.
Construisez depuis application. -t attribue l’URI et l’étiquette de version. Le dernier argument est le contexte de construction, dont les fichiers sont accessibles à COPY :
docker build -t "${REPOSITORY_URI}:release-1" application
Publiez l’image. Docker envoie les couches du système de fichiers et le manifest qui décrit le contenu :
docker push "${REPOSITORY_URI}:release-1"
Docker affiche ensuite un digest sha256:.... Un digest identifie le contenu exact ; une étiquette est un nom. Même si un dépôt autorise le changement d’étiquette, le digest reste lié au contenu initial.
Interrogez ECR pour confirmer la version stockée :
aws ecr describe-images \
--repository-name ct-demo \
--image-ids imageTag=release-1 \
--query 'imageDetails[0].{Tags:imageTags,Digest:imageDigest}'
Enregistrez également son digest dans une variable :
IMAGE_DIGEST=$(aws ecr describe-images \
--repository-name ct-demo \
--image-ids imageTag=release-1 \
--query 'imageDetails[0].imageDigest' \
--output text)
Le digest ECR doit correspondre à celui de docker push. Dans AWS View, en haut, ct-demo contient release-1 et son digest. L’application ne tourne pas encore ; vous la démarrerez ensuite.
Exécuter l’image exacte publiée
Dans cette étape, récupérez l’image par digest et testez un véritable conteneur applicatif.
Supprimez d’abord l’image construite localement. docker image rm retire une référence locale, pas l’image conservée dans ECR. La récupération suivante utilise donc la version publiée :
docker image rm "${REPOSITORY_URI}:release-1"
Associez l’URI et le digest avec @ pour sélectionner le contenu exact :
docker pull "${REPOSITORY_URI}@${IMAGE_DIGEST}"
Docker indique le même digest et un téléchargement réussi. Démarrez-le sous le nom ct01-app. --detach exécute en arrière-plan ; --publish 127.0.0.1:8081:8000 relie le port hôte 8081 au port applicatif 8000. L’adresse de bouclage limite l’accès direct à cette VM. L’image choisit déjà un utilisateur non privilégié ; --read-only rend la racine accessible uniquement en lecture, --cap-drop ALL retire les capacités Linux et no-new-privileges empêche l’acquisition de privilèges supplémentaires :
docker run --detach \
--name ct01-app \
--read-only \
--cap-drop ALL \
--security-opt no-new-privileges \
--memory 256m \
--publish 127.0.0.1:8081:8000 \
"${REPOSITORY_URI}@${IMAGE_DIGEST}"
L’ID signifie que Docker a accepté le démarrage, sans prouver la santé de l’application. Testez HTTP : curl --fail échoue sur une erreur HTTP et --retry-all-errors réessaie les erreurs de démarrage, y compris une brève réinitialisation de connexion :
curl --fail --silent --show-error \
--retry 5 --retry-all-errors --retry-delay 1 \
http://127.0.0.1:8081/
La réponse JSON doit contenir "release": "release-1" et le nom d’hôte du conteneur. Consultez les journaux pour confirmer la requête réelle :
docker logs ct01-app
Vous devez voir served application request. Le nom d’hôte et les horodatages varient. Dans AWS View, en haut, sélectionnez Request application : la réponse doit également indiquer release-1. Ce bouton adresse réellement une requête HTTP au conteneur.

Supprimer vos ressources applicatives
Dans cette étape, arrêtez l’application et supprimez son image locale et son dépôt ECR en préservant le dépôt de référence.
Arrêtez d’abord le conteneur :
docker stop ct01-app
Supprimez-le ensuite. Supprimer un conteneur ne supprime pas son image :
docker rm ct01-app
Aucun conteneur en cours d’exécution ne l’utilisant, retirez la référence locale par digest :
docker image rm "${REPOSITORY_URI}@${IMAGE_DIGEST}"
Supprimez l’image d’ECR par digest. imageDigest sélectionne précisément le contenu sans dépendre d’une étiquette :
aws ecr batch-delete-image \
--repository-name ct-demo \
--image-ids imageDigest="$IMAGE_DIGEST"
La réponse doit énumérer l’image supprimée sous imageIds avec une liste failures vide. Supprimez le dépôt applicatif désormais vide :
aws ecr delete-repository --repository-name ct-demo
Confirmez la présence du dépôt de référence :
aws ecr describe-repositories \
--query 'repositories[].repositoryName'
Vous devez voir uniquement ct-reference. Enfin, retirez la connexion au registre enregistrée par Docker :
docker logout "$REGISTRY"
Dans AWS View, en haut, ct-demo et le conteneur disparaissent ; le dépôt de référence reste présent. Une erreur HTTP seule ne prouve pas le nettoyage : vous avez aussi inspecté l’inventaire et supprimé le conteneur et l’image réels.
Résumé
Vous avez créé un dépôt ECR immuable, construit et publié une image, comparé son digest et exécuté cette version exacte. Vous avez vérifié les réponses HTTP et les journaux réels, puis supprimé votre conteneur, votre image locale et votre dépôt tout en préservant celui d’une autre application. Le prochain laboratoire utilise une définition de tâche ECS pour choisir et exécuter une image.
Pour approfondir ce sujet, consultez la documentation AWS : Authentification du registre et envoi d’images; Empêcher l’écrasement des étiquettes d’images.



