{"id":18429127,"url":"https://github.com/openliberty/guide-cloud-aws","last_synced_at":"2025-04-07T17:32:47.907Z","repository":{"id":38235995,"uuid":"175879561","full_name":"OpenLiberty/guide-cloud-aws","owner":"OpenLiberty","description":"A guide on how to deploy microservices to Amazon Elastic Container Service for Kubernetes (EKS) on Amazon Web Services (AWS): https://openliberty.io/guides/cloud-aws.html","archived":false,"fork":false,"pushed_at":"2024-09-05T13:52:48.000Z","size":437,"stargazers_count":12,"open_issues_count":2,"forks_count":10,"subscribers_count":5,"default_branch":"prod","last_synced_at":"2024-09-05T22:48:17.258Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/OpenLiberty.png","metadata":{"files":{"readme":"README.adoc","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-03-15T19:28:37.000Z","updated_at":"2024-09-05T13:52:52.000Z","dependencies_parsed_at":"2024-04-23T17:48:16.892Z","dependency_job_id":"39c17379-fc64-4eb0-8e55-6601edbca63a","html_url":"https://github.com/OpenLiberty/guide-cloud-aws","commit_stats":null,"previous_names":[],"tags_count":7,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenLiberty%2Fguide-cloud-aws","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenLiberty%2Fguide-cloud-aws/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenLiberty%2Fguide-cloud-aws/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenLiberty%2Fguide-cloud-aws/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/OpenLiberty","download_url":"https://codeload.github.com/OpenLiberty/guide-cloud-aws/tar.gz/refs/heads/prod","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":223286329,"owners_count":17120002,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-06T05:15:56.616Z","updated_at":"2024-11-06T05:15:57.148Z","avatar_url":"https://github.com/OpenLiberty.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"//\n// Copyright (c) 2019, 2024 IBM Corporation and others.\n// Licensed under Creative Commons Attribution-NoDerivatives\n// 4.0 International (CC BY-ND 4.0)\n//   https://creativecommons.org/licenses/by-nd/4.0/\n//\n// Contributors:\n//     IBM Corporation\n//\n:projectid: cloud-aws\n:page-layout: guide-multipane\n:page-duration: 45 minutes\n:page-releasedate: 2019-05-29\n:page-description: Explore how to deploy microservices to Amazon Elastic Container Service for Kubernetes (EKS) on Amazon Web Services (AWS).\n:page-tags: ['kubernetes', 'docker', 'cloud']\n:page-permalink: /guides/{projectid}\n:page-related-guides: ['kubernetes-intro', 'kubernetes-microprofile-config', 'kubernetes-microprofile-health', 'istio-intro']\n:common-includes: https://raw.githubusercontent.com/OpenLiberty/guides-common/prod\n:source-highlighter: prettify\n:page-seo-title: Deploying Java microservices on Amazon Web Services (AWS) with Kubernetes\n:page-seo-description: A getting started tutorial with examples on how to deploy Java microservices to Amazon Elastic Container Service for Kubernetes (EKS) using Amazon Elastic Container Registry (ECR) as a private container registry.\n:guide-author: Open Liberty\n= Deploying microservices to Amazon Web Services\n\n[.hidden]\nNOTE: This repository contains the guide documentation source. To view the guide in published form, view it on the https://openliberty.io/guides/{projectid}.html[Open Liberty website^].\n\nExplore how to deploy microservices to Amazon Elastic Container Service for Kubernetes (EKS) on Amazon Web Services (AWS).\n\n:kube: Kubernetes\n:hashtag: #\n:win: WINDOWS\n:mac: MAC\n:linux: LINUX\n:system-api: http://[hostname]:31000/system/properties\n:inventory-api: http://[hostname]:32000/inventory/systems\n\n\n// =================================================================================================\n// Introduction\n// =================================================================================================\n\n== What you'll learn\n\nYou will learn how to deploy two microservices in Open Liberty containers to a {kube} cluster on Amazon Elastic Container Service for Kubernetes (EKS). \n\nKubernetes is an open-source container orchestrator that automates many tasks that are involved in deploying, managing, and scaling containerized applications. If you would like to learn more about Kubernetes, check out the https://openliberty.io/guides/kubernetes-intro.html[Deploying microservices to Kubernetes^] guide.\n\nThere are different cloud-based solutions for running your Kubernetes workloads. Cloud-based infrastructure enables you to focus on developing your microservices without worrying about low-level infrastructure details for deployment. Using a cloud helps you to easily scale and manage your microservices in a high-availability setup.\n\nAmazon Web Services (AWS) offers a managed Kubernetes service called Amazon Elastic Container Service for {kube} (EKS). EKS simplifies the process of running Kubernetes on AWS without needing to install or maintain your Kubernetes control plane. It provides a hosted {kube} cluster where you can deploy your microservices. You will use EKS with Amazon Elastic Container Registry (ECR). Amazon ECR is a private registry that is used to store and distribute your container images. Note, because EKS is not free, there is a small cost that is associated with running this guide. See the official https://aws.amazon.com/eks/pricing/[Amazon EKS pricing^] documentation for more details.\n\nThe two microservices you will deploy are called `system` and `inventory`. The `system` microservice returns the JVM system properties of the running container. It also returns the pod’s name in the HTTP header, making replicas easy to distinguish from each other. The `inventory` microservice adds the properties from the `system` microservice to the inventory. This demonstrates how communication can be established between pods inside a cluster.\n\n\n// =================================================================================================\n// Prerequisites\n// =================================================================================================\n\n== Additional prerequisites\n\nBefore you begin, the following additional tools need to be installed:\n\n* *Docker:* You need containerization software for building containers. Kubernetes supports various container types, but you will use Docker in this guide. For installation instructions, refer to the official https://docs.docker.com/install/[Docker^] documentation.\n\n* *kubectl:* You need the Kubernetes command-line tool `kubectl` to interact with your Kubernetes cluster. See the official https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl[Install and Set Up kubectl^] documentation for information about downloading and setting up `kubectl` on your platform.\n\n* *eksctl:* In this guide, you will use the `eksctl` Command Line Interface (CLI) tool for provisioning your EKS cluster. Navigate to the https://github.com/weaveworks/eksctl/releases[eksctl releases page^] and download the latest stable release. Extract the archive and add the directory with the extracted files to your path.\n\n* *AWS CLI:* You will need to use the AWS Command Line Interface (CLI). For this guide, use AWS CLI Version 2, which supports IAM authentication for your Amazon EKS cluster and is intended for use in production environments. All installers for AWS CLI version 2 include and use an embedded copy of Python, which operates independently of any other Python version installed on your system. Install the AWS CLI by following the instructions in the official https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html[Installing the AWS CLI^] documentation. \n\nTo verify that the AWS CLI is installed correctly, run the following command:\n\n[role=command]\n```\naws --version\n```\n\n\n\n// =================================================================================================\n// Getting Started\n// =================================================================================================\n\n[role=command]\ninclude::{common-includes}/gitclone.adoc[]\n\n// no \"try what you'll build\" section in this guide because it would be too long due to all setup the user will have to do.\n\n\n// =================================================================================================\n// Creating a Kubernetes cluster on EKS\n// =================================================================================================\n\n== Creating a Kubernetes cluster on EKS\n\nBefore you can deploy your microservices, you must create a {kube} cluster.\n\n// =================================================================================================\n// Configuring the AWS CLI\n// =================================================================================================\n\n=== Configuring the AWS CLI\n\nBefore you configure the AWS CLI, you need to create an AWS Identity and Access Management (IAM) user. Navigate to the https://console.aws.amazon.com/iam/home#/users[Identity and Access Management^] users dashboard and create a user through the UI. When you create the user, select `programmatic access` as the AWS access type. You will be prompted to set permissions for the user. To complete this guide, the created user must have the following minimal access levels:\n\n* Refer to the https://eksctl.io/usage/minimum-iam-policies/[Minimum IAM Policies^] for the main use cases of `eksctl`.\n* Ensure that the https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryFullAccess[AmazonEC2ContainerRegistryFullAccess^] policy is attached to the IAM account. This policy grants full access to the Amazon Elastic Container Registry, which is necessary for managing container images for your EKS cluster.\n\nMake sure to copy the `AWS Access Key ID` and `AWS Secret Access Key` values, as you will need these to configure the AWS CLI. After the AWS CLI is installed, configure it by running the `aws configure` command. You will be prompted to provide the `AWS Access Key ID` and `AWS Secret Access Key` values that are associated with the IAM user you created.\n\n[role=command]\n```\naws configure\n```\n\nNext, you will be prompted to enter a region. This region will be the region of the servers where your requests are sent. Select the region that is closest to you. For a full list of regions, see the https://docs.aws.amazon.com/general/latest/gr/rande.html#eks_region[AWS Regions and Endpoints^].\n\nFinally, enter `json` when you are prompted to enter the output format. \n\nAfter you are done filling out this information, the settings are stored in the default profile. Anytime that you run an AWS CLI command without specifying a profile, the default profile is used. \n\nYou can verify your current configuration values by running the following command: \n[role=command]\n```\naws configure list\n```\n\n// =================================================================================================\n// Provisioning a cluster\n// =================================================================================================\n\n=== Provisioning a cluster\n\nThe `eksctl` CLI tool simplifies the process of creating clusters on EKS. By default, the command includes a single `t2.small` Amazon Elastic Compute Cloud (EC2) instance that supports both `i386` and `x86_64` architectures. However, this instance is not covered under the AWS Free Tier. For more information, see the official link:https://aws.amazon.com/ec2/pricing/on-demand/[Amazon EC2 pricing^] documentation.\n\nIf you need to build Docker images using other architectures, such as `ARM64`, you must switch the instance type accordingly. To view the AWS supported instance types, use the navigation bar in EC2 home to select **Instances** \u003e **Instance Types**. \n\nTo create your cluster, use the `eksctl create cluster` command:\n\n[role=command]\n```\neksctl create cluster --name=guide-cluster --nodes=1 --node-type=t2.small\n```\n\nRunning this command creates a cluster that is called `guide-cluster` that uses a single `t2.small` instance as the worker node. When the cluster is created, you will see an output similar to the following example:\n\n[source, role=\"no_copy\"]\n```\n[✔]  EKS cluster \"guide-cluster\" in \"us-east-2\" region is ready\n```\n\nAfter your cluster is ready, EKS connects `kubectl` to the cluster. Verify that you're connected to the cluster by checking the cluster's nodes:\n\n[role=command]\n```\nkubectl get nodes\n```\n\n[source, role=\"no_copy\"]\n----\nNAME                                           STATUS   ROLES    AGE   VERSION\nip-192-168-47-186.us-east-2.compute.internal   Ready    \u003cnone\u003e   30m   v1.30.4-eks-a737599\n----\n\n// =================================================================================================\n// Deploying microservices to Amazon Elastic Container Service for Kubernetes (EKS)\n// =================================================================================================\n\n== Deploying microservices to Amazon Elastic Container Service for Kubernetes (EKS)\n\nIn this section, you will learn how to deploy two microservices in Open Liberty containers to a {kube} cluster on EKS. You will build and containerize the `system` and `inventory` microservices, push them to a container registry, and then deploy them to your {kube} cluster. \n\n// =================================================================================================\n// Building and containerizing the microservices\n// =================================================================================================\n\n=== Building and containerizing the microservices\n\nThe first step of deploying to {kube} is to build your microservices and containerize them.\n\nThe starting Java project, which you can find in the `start` directory, is a multi-module Maven project. It is made up of the `system` and `inventory` microservices. Each microservice resides in its own directory, `start/system` and `start/inventory`. Both of these directories contain a Dockerfile, which is necessary for building the Docker images. If you're unfamiliar with Dockerfiles, check out the https://openliberty.io/guides/containerize.html[Containerizing microservices^] guide.\n\nTo build these microservices, navigate to the `start` directory and run the following command:\n\n[role=command]\n```\nmvn package\n```\n\nNext, run the `docker build` commands to build the container images for your application:\n[role='command']\n```\ndocker build --platform linux/amd64 -t system:1.0-SNAPSHOT system/.\ndocker build --platform linux/amd64 -t inventory:1.0-SNAPSHOT inventory/.\n```\n\nThe `-t` flag in the `docker build` command allows the Docker image to be labeled (tagged) in the `name[:tag]` format. The tag for an image describes the specific image version. If the optional `[:tag]` tag is not specified, the `latest` tag is created by default.\n\nDuring the build, you see various Docker messages that describe what images are being downloaded and built. When the build finishes, run the following command to list all local Docker images:\n\n[role=command]\n```\ndocker images\n```\n\nVerify that the `system:1.0-SNAPSHOT` and `inventory:1.0-SNAPSHOT` images are listed among them, for example:\n\n[source, role=\"no_copy\"]\n----\nREPOSITORY                        TAG\nsystem                            1.0-SNAPSHOT\ninventory                         1.0-SNAPSHOT\nicr.io/appcafe/open-liberty       kernel-slim-java11-openj9-ubi       \n----\n\nIf you don't see the `system:1.0-SNAPSHOT` and `inventory:1.0-SNAPSHOT` images, then check the Maven build log for any potential errors.\n\n// =================================================================================================\n// Pushing the images to a docker registry\n// =================================================================================================\n\n=== Pushing the images to a container registry\n\nPushing the images to a registry allows the cluster to create pods by using your container images. The registry that you are using is called Amazon Elastic Container Registry (ECR).\n\nFirst, you must authenticate your Docker client to your ECR registry. Start by running the `get-login` command:\n[role=command]\n```\naws ecr get-login-password\n```\n\nThe `get-login` command returns a `[password_string]`; take a note of this `[password_string]`. Next, running the following will return the `[aws_account_id]` needed to authenticate your Docker client. \n\n[role=command]\n```\naws sts get-caller-identity --output text --query \"Account\"\n```\n\nThe `[aws_account_id]` is a unique 12-digit ID that is assigned to every AWS account. You will notice this ID in the output from various commands because AWS uses it to differentiate your resources from other accounts. \n\nReplace the `[password_string]`, `[aws_account_id]` and the `[region]` your account is configured under in the following `docker login` command, that is used to authenticate your Docker client. \n\n[role=command]\n```\ndocker login -u AWS -p [password_string] https://[aws_account_id].dkr.ecr.[region].amazonaws.com\n```\n\nNext, make a repository to store the `system` and `inventory` images:\n[role=command]\n```\naws ecr create-repository --repository-name awsguide/system\naws ecr create-repository --repository-name awsguide/inventory\n```\n\nYou will see an output similar to the following:\n\n[source, role=\"no_copy\"]\n```\n{\n    \"repository\": {\n        \"registryId\": \"[aws_account_id]\",\n        \"repositoryName\": \"awsguide/system\",\n        \"repositoryArn\": \"arn:aws:ecr:[region]:[aws_account_id]:repository/awsguide/system\",\n        \"createdAt\": 1553111916.0,\n        \"repositoryUri\": \"[aws_account_id].ecr.[region].amazonaws.com/awsguide/system\"\n    }\n}\n```\n\nTake note of the repository URI for both the `system` and `inventory` repositories, as you need them when you tag and push your images.\n\n// Tagging images\nNext, you need to tag your container images with the relevant data about your registry:\n\n[role=command]\n```\ndocker tag system:1.0-SNAPSHOT [system-repository-uri]:1.0-SNAPSHOT\ndocker tag inventory:1.0-SNAPSHOT [inventory-repository-uri]:1.0-SNAPSHOT\n```\n\n// Pushing images\nFinally, push your images to the registry:\n\n[role=command]\n```\ndocker push [system-repository-uri]:1.0-SNAPSHOT\ndocker push [inventory-repository-uri]:1.0-SNAPSHOT\n```\n\nWhen you tag and push your images, remember to substitute `[system-repository-uri]` and `[inventory-repository-uri]` with the appropriate URI for the system and inventory repositories. \n\n// =================================================================================================\n// Deploying the microservices\n// =================================================================================================\n\n=== Deploying the microservices\n\nNow that your container images are built, deploy them using a Kubernetes resource definition.\n\nA Kubernetes resource definition is a yaml file that contains a description of all your deployments, services, or any other resources that you want to deploy. All resources can also be deleted from the cluster by using the same yaml file that you used to deploy them. The `kubernetes.yaml` resource definition file is provided for you. If you are interested in learning more about the Kubernetes resource definition, check out the https://openliberty.io/guides/kubernetes-intro.html[Deploying microservices to Kubernetes^] guide.\n\n[role=\"code_command hotspot\", subs=\"quotes\"]\n----\n#Update the `kubernetes.yaml` file in the `start` directory.#\n`kubernetes.yaml`\n----\n\nkubernetes.yaml\n[source, yaml, linenums, role='code_column']\n----\ninclude::finish/kubernetes.yaml[]\n----\n[role=\"edit_command_text\"]\nThe [hotspot=18 hotspot=39]`image` is the name and tag of the container image that you want to use for the container. Update the system [hotspot=18]`image` and the inventory [hotspot=39]`image` fields to point to your `system` and `inventory` repository URIs.\n\n\nRun the following commands to deploy the resources as defined in kubernetes.yaml:\n[role='command']\n```\nkubectl apply -f kubernetes.yaml\n```\n\nWhen the apps are deployed, run the following command to check the status of your pods:\n[role='command']\n```\nkubectl get pods\n```\n\nIf all the pods are healthy and running, you see an output similar to the following:\n[source, role=\"no_copy\"]\n----\nNAME                                    READY     STATUS    RESTARTS   AGE\nsystem-deployment-6bd97d9bf6-4ccds      1/1       Running   0          15s\ninventory-deployment-645767664f-nbtd9   1/1       Running   0          15s\n----\n\n=== Making requests to the microservices\n\nBefore you can make a request to `[hostname]:31000` or `[hostname]:32000`, you must modify the security group to allow incoming traffic through ports `31000` and `32000`. To get the `group-id` of the security group, use the `aws ec2 describe-security-groups` command:\n[role=command]\n```\naws ec2 describe-security-groups --filters Name=group-name,Values=\"*eksctl-guide-cluster-cluster-*\" --query \"SecurityGroups[*].IpPermissions[*].UserIdGroupPairs\"\n```\n\nYou will see an output similar to the following:\n\n[source, role=\"no_copy\"]\n```\n...\n    {\n        \"Description\": \"Allow nodes to communicate with each other (all ports)\",\n        \"GroupId\": \"sg-035c858e1ff9c52f1\",\n        \"UserId\": \"208872073932\"\n    },\n    {\n        \"Description\": \"Allow managed and unmanaged nodes to communicate with each other (all ports)\",\n        \"GroupId\": \"sg-04a0c50049c10ae54\",\n        \"UserId\": \"208872073932\"\n    }\n...\n```\n\nCopy the value of the `GroupId` which description is \"Allow managed and unmanaged nodes to communicate with each other (all ports)\". In this example output, the value is `sg-04a0c50049c10ae54`.\n\nThen, add the following rules to the security group to allow incoming traffic through ports `31000` and `32000`. Don't forget to substitute `[security-group-id]` for the `GroupId` in the output of the previous command.\n\n[role=command]\n```\naws ec2 authorize-security-group-ingress --protocol tcp --port 31000 --group-id [security-group-id] --cidr 0.0.0.0/0\naws ec2 authorize-security-group-ingress --protocol tcp --port 32000 --group-id [security-group-id] --cidr 0.0.0.0/0\n```\n\nAfter you finish adding the inbound rules to the security group, you might need to wait a few minutes before you try to access the `system` and `inventory` microservices.\n\nTake note of the `EXTERNAL-IP` in the output of the following command. It is the hostname you will later substitute into `[hostname]`: \n[role=command]\n```\nkubectl get nodes -o wide\n```\n\nThen, `curl` or visit the following URLs to access your microservices, substituting the appropriate hostname:\n\n* `{system-api}`\n* `{inventory-api}/system-service`\n\nThe first URL returns system properties and the name of the pod in an HTTP header called `X-Pod-Name`. To view the header, you can use the `-I` option in the `curl` when you make a request to `{system-api}`. The second URL adds properties from `system-service` to the inventory.\n\n// =================================================================================================\n// Testing microservices that are running on AWS EKS\n// =================================================================================================\n\n== Testing microservices that are running on AWS EKS\n\npom.xml\n[source, xml, linenums, role='code_column']\n----\ninclude::finish/inventory/pom.xml[]\n----\n\nA few tests are included for you to test the basic functionality of the microservices. If a test failure occurs, then you might have introduced a bug into the code. To run the tests, wait for all pods to be in the ready state before you proceed further. The default properties defined in the [hotspot]`pom.xml` file are:\n\n[cols=\"15, 100\", options=\"header\"]\n|===\n| *Property*                                | *Description*\n| [hotspot=cluster file=0]`cluster.ip`                         | IP or hostname for your cluster.\n| [hotspot=system-service file=0]`system.kube.service`         | Name of the Kubernetes Service wrapping the `system` pods, `system-service` by default.\n| [hotspot=system-node-port file=0]`system.node.port`          | The NodePort of the Kubernetes Service `system-service`, 31000 by default.\n| [hotspot=inventory-node-port file=0]`inventory.node.port`    | The NodePort of the Kubernetes Service `inventory-service`, 32000 by default.\n|===\n\nUse the following command to run the integration tests against your cluster. Substitute `[hostname]` with the appropriate value:\n\n[role=command]\n```\nmvn failsafe:integration-test -Dcluster.ip=[hostname]\n```\n\nIf the tests pass, you see an output for each service similar to the following:\n\n[source, role=\"no_copy\"]\n----\n\n-------------------------------------------------------\n T E S T S\n-------------------------------------------------------\nRunning it.io.openliberty.guides.system.SystemEndpointIT\nTests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.673 sec - in it.io.openliberty.guides.system.SystemEndpointIT\n\nResults:\n\nTests run: 2, Failures: 0, Errors: 0, Skipped: 0\n----\n\n[source, role=\"no_copy\"]\n----\n-------------------------------------------------------\n T E S T S\n-------------------------------------------------------\nRunning it.io.openliberty.guides.inventory.InventoryEndpointIT\nTests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.222 sec - in it.io.openliberty.guides.inventory.InventoryEndpointIT\n\nResults:\n\nTests run: 4, Failures: 0, Errors: 0, Skipped: 0\n----\n\n== Deploying new version of system microservice\n\nOptionally, you might want to make changes to your microservice and learn how to redeploy the updated version of your microservice. In this section, you will bump the version of the `system` microservice to `2.0-SNAPSHOT` and redeploy the new version of the microservice.\n\nUse Maven to repackage your microservice:\n[role=command]\n```\nmvn package\n```\n\nNext, build the new version of the container image as `2.0-SNAPSHOT`:\n[role=command]\n```\ndocker build --platform linux/amd64 -t system:2.0-SNAPSHOT system/.\n```\n\nSince you built a new image, it must be pushed to the `awsguide/system` repository of your container registry again.\n\n// Tagging images\nTag your container image with the relevant data about your registry:\n\n[role=command]\n```\ndocker tag system:2.0-SNAPSHOT [system-repository-uri]:2.0-SNAPSHOT\n```\n\n// Pushing images\nPush your image to the registry:\n\n[role=command]\n```\ndocker push [system-repository-uri]:2.0-SNAPSHOT\n```\n\nUpdate the `system-deployment` deployment to use the new container image that you just pushed to the registry:\n\n[role=command]\n```\nkubectl set image deployment/system-deployment system-container=[system-repository-uri]:2.0-SNAPSHOT\n```\n\nUse the following command to find the name of the pod that is running the `system` microservice:\n\n[role=command]\n```\nkubectl get pods\n```\n\n[source, role=\"no_copy\"]\n----\nNAME                                   READY     STATUS    RESTARTS   AGE\ninventory-deployment-6fd959cc4-rf2m2   1/1       Running   0          7m\nsystem-deployment-677b9f5d9c-nqzcf     1/1       Running   0          7m\n----\n\nObserve that in this case, the `system` microservice is running in the pod called `system-deployment-677b9f5d9c-nqzcf`. Substitute the name of your pod into the following command to see more details about the pod:\n\n[role=command]\n```\nkubectl get event --field-selector involvedObject.name=[pod-name]\n```\n\nView the events at the bottom of the command's output. Notice that the pod is using the new container image `system:2.0-SNAPSHOT`.\n\n[source, role=\"no_copy\"]\n----\nLAST SEEN   TYPE     REASON      OBJECT                                   MESSAGE\n97s         Normal   Scheduled   pod/system-deployment-56b4b765d4-9jz5l   Successfully assigned default/system-deployment-56b4b765d4-9jz5l to ip-192-168-85-136.us-east-2.compute.internal\n97s         Normal   Pulling     pod/system-deployment-56b4b765d4-9jz5l   Pulling image \"208872073932.dkr.ecr.us-east-2.amazonaws.com/awsguide/system:2.0-SNAPSHOT\"\n95s         Normal   Pulled      pod/system-deployment-56b4b765d4-9jz5l   Successfully pulled image \"208872073932.dkr.ecr.us-east-2.amazonaws.com/awsguide/system:2.0-SNAPSHOT\" in 1.082459294s\n95s         Normal   Created     pod/system-deployment-56b4b765d4-9jz5l   Created container system-container\n95s         Normal   Started     pod/system-deployment-56b4b765d4-9jz5l   Started container system-container\n----\n\n// =================================================================================================\n// Tear Down\n// =================================================================================================\n\n== Tearing down the environment\n\nIt is important to clean up your resources when you are finished with the guide so that you do not incur additional charges for ongoing service.\n\nWhen you no longer need your deployed microservices, you can delete all {kube} resources by running the `kubectl delete` command:\n[role='command']\n```\nkubectl delete -f kubernetes.yaml\n```\n\nDelete the ECR repositories used to store the `system` and `inventory` images:\n[role=command]\n```\naws ecr delete-repository --repository-name awsguide/system --force\naws ecr delete-repository --repository-name awsguide/inventory --force\n```\n\nRemove your EKS cluster:\n[role=command]\n```\neksctl delete cluster --name guide-cluster\n```\n\n\n// =================================================================================================\n// finish\n// =================================================================================================\n\n== Great work! You're done!\n\nYou just deployed two microservices running in Open Liberty to AWS EKS. You also learned how to use the `kubectl` command to deploy your microservices on a {kube} cluster.\n\n// Multipane\ninclude::{common-includes}/attribution.adoc[subs=\"attributes\"]\n\n// DO NO CREATE ANYMORE SECTIONS AT THIS POINT\n// Related guides will be added in automatically here if you included them in \":page-related-guides\"\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenliberty%2Fguide-cloud-aws","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenliberty%2Fguide-cloud-aws","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenliberty%2Fguide-cloud-aws/lists"}