Docker - WordPress Deploy to ECS with Docker-Compose (ECS-CLI EC2 type)

We can use Docker Compose files in any format (v1, v2, or v3) to deploy containers using the Amazon ECS CLI (Amazon ECS CLI Supports Docker Compose Version 3).

Let's install ECS CLI (Amazon ECS Command Line Reference) on Mac (Installing the Amazon ECS CLI):

$ sudo curl -o /usr/local/bin/ecs-cli https://s3.amazonaws.com/amazon-ecs-cli/ecs-cli-darwin-amd64-latest

Verify the downloaded binary with the MD5 sum provided. Compare the two output strings (the checksum that is returned from local md5 run should match the from on the S3 source):

$ curl -s https://s3.amazonaws.com/amazon-ecs-cli/ecs-cli-darwin-amd64-latest.md5 && md5 -q /usr/local/bin/ecs-cli
4ff2288545af59bb2e68750a45d5ac00
4ff2288545af59bb2e68750a45d5ac00

Apply execute permissions to the binary:

$ sudo chmod +x /usr/local/bin/ecs-cli

Verify that the CLI is working properly by checking the versio:

$ ecs-cli --version
ecs-cli version 1.12.1 (e70f1b1)

The Amazon ECS CLI requires some basic configuration information (Configuring the Amazon ECS CLI) before we can use it, such as our AWS credentials, the AWS Region in which to create our cluster, and the name of the Amazon ECS cluster to use.

Starting from v1.0.0, the new YAML formatted configuration files are splitt into two separate files. Credential information is stored in ~/.ecs/credentials and cluster configuration information is stored in ~/.ecs/config.

Set up a CLI profile with the following command, substituting profile_name with desired profile name, $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY environment variables with our AWS credentials. Let's set "wordpress" as a default profile:

$ ecs-cli configure profile --profile-name wordpress --access-key $AWS_ACCESS_KEY_ID --secret-key $AWS_SECRET_ACCESS_KEY

$ cat ~/.ecs/credentials
version: v1
default: wordpress
ecs_profiles:
  wordpress:
    aws_access_key_id: AKIAIY6RID2W2C5I3P5Q
    aws_secret_access_key: KLjk4Axhz1N2852p0r9iTvn2aJltNOjSQCIygVjb

If we want to set a default config-name, follow this example below which configures the Amazon ECS CLI to set the ec2-tutorial cluster configuration as the default.

$ ecs-cli configure default --config-name ec2-tutorial

$ cat ~/.ecs/config
version: v1
default: ec2-tutorial
clusters:
  ec2-tutorial:
    cluster: ec2-tutorial
    region: us-east-1
    default_launch_type: EC2
  wordpress:
    cluster: wordpress
    region: us-east-1
    default_launch_type: EC2

Then, create a cluster configuration:

ecs-cli configure --cluster cluster_name --default-launch-type launch_type --region region_name --config-name configuration_name

$ ecs-cli configure --cluster wordpress --region us-east-1 --default-launch-type EC2 --config-name wordpress

The ecs-cli configure command configures the AWS Region to use, resource creation prefixes, and the Amazon ECS cluster name to use with the Amazon ECS CLI. Stores a single named cluster configuration in the ~/.ecs/config file. The first cluster configuration that is created is set as the default.

$ cat ~/.ecs/config
version: v1
default: wordpress
clusters:
  wordpress:
    cluster: wordpress
    region: us-east-1
    default_launch_type: EC2

The next action we should take is to create a cluster of Amazon ECS container instances that we can launch our containers on with the ecs-cli up command.

The ecs-cli up command creates the Amazon ECS cluster (if it does not already exist) and the AWS resources required to set up the cluster (ecs-cli up).

This command creates a new AWS CloudFormation stack called amazon-ecs-cli-setup-cluster_name. We can view the progress of the stack creation in the AWS Management Console.

The following command brings up a cluster of 1 t2.micto instance and configures them to use the EC2 key pair provided. It will use EC2 Launch Type. The name of the cluster is set to wordpress. Note that we use a keypair einsteinish.pem but without the pem extension. Otherwise, we may get the keypair does not exist error:

$ ecs-cli up --keypair einsteinish --capability-iam --size 1 --instance-type t2.micro --cluster wordpress
INFO[0001] Using recommended Amazon Linux 2 AMI with ECS Agent 1.22.0 and Docker version 18.06.1-ce 
INFO[0006] Created cluster                               cluster=wordpress region=us-east-1
INFO[0007] Waiting for your cluster resources to be created... 
INFO[0007] Cloudformation stack status                   stackStatus=CREATE_IN_PROGRESS
INFO[0069] Cloudformation stack status                   stackStatus=CREATE_IN_PROGRESS
INFO[0131] Cloudformation stack status                   stackStatus=CREATE_IN_PROGRESS
VPC created: vpc-0788e613566d307e5
Security Group created: sg-01a20a06be03b7b4d
Subnet created: subnet-08dce2099d47fb07c
Subnet created: subnet-0e5aca767db43b163
Cluster creation succeeded.

Here is the resources created via Cloudformation:

The resources were created using the following parameters:

Note that we used the --force param to let Cloudformation know that we need a complete stack recreation (in case when we already have a previous stack and we want to replace it).

Warning - the "--cluster-config wordpress" does not seem to take the correct cluster_name (it takes ecs-demo-cluste as the culster's name instead). So, in the command, I had to specify the name with "--cluster wordpress".

As mentioned earlier, the Cloudformation prepended "amazon-ecs-cli-setup-" to the specified parameter provided, "wordpress". So, the name is "amazon-ecs-cli-setup-wordpress".

Now, we created our cluster:

For this step, we'll create a simple Docker compose file that creates a WordPress application consisting of a web server and a MySQL database. At this time, the Amazon ECS CLI supports Docker compose file syntax versions 1, 2, and 3.

Here is our compose file (docker-compose.yml) from Tutorial: Creating a Cluster with an EC2 Task Using the Amazon ECS CLI:

version: '3'
services:
  wordpress:
    image: wordpress
    ports:
      - "80:80"
    links:
      - mysql
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: password

When using Docker Compose version 3 format, the CPU and memory specifications must be specified separately. Create a file named ecs-params.yml with the following content:

version: 1
task_definition:
  services:
    wordpress:
      cpu_shares: 100
      mem_limit: 262144000
    mysql:
      cpu_shares: 100
      mem_limit: 262144000

Note that each container has 100 CPU units and 250 MiB of memory. The wordpress container exposes port 80 to the container instance for inbound traffic to the web server.

Now that we created the compose file, we can deploy it to our cluster with the ecs-cli compose up command. By default, the command looks for a compose file (docker-compose.yml) and an optional ECS parameters file (ecs-params.yml) in the current directory, but we can specify a different file with the --file option.

By default, the resources created by this command have the current directory in the title, but we can override that with the --project-name project_name option.

$ ecs-cli compose up --cluster wordpress --cluster-config wordpress --force-update
INFO[0001] Using ECS task definition                     TaskDefinition="ECS-WORDPRESS:6"
INFO[0001] Starting container...                         container=3f479b81-8c44-48c9-ac66-12d62828f19d/wordpress
INFO[0001] Starting container...                         container=3f479b81-8c44-48c9-ac66-12d62828f19d/mysql
INFO[0002] Describe ECS container status                 container=3f479b81-8c44-48c9-ac66-12d62828f19d/wordpress desiredStatus=RUNNING lastStatus=PENDING taskDefinition="ECS-WORDPRESS:6"
INFO[0002] Describe ECS container status                 container=3f479b81-8c44-48c9-ac66-12d62828f19d/mysql desiredStatus=RUNNING lastStatus=PENDING taskDefinition="ECS-WORDPRESS"
INFO[0015] Describe ECS container status                 container=3f479b81-8c44-48c9-ac66-12d62828f19d/wordpress desiredStatus=RUNNING lastStatus=PENDING taskDefinition="ECS-WORDPRESS:6"
INFO[0015] Describe ECS container status                 container=3f479b81-8c44-48c9-ac66-12d62828f19d/mysql desiredStatus=RUNNING lastStatus=PENDING taskDefinition="ECS-WORDPRESS"
INFO[0027] Stopped container...                          container=3f479b81-8c44-48c9-ac66-12d62828f19d/wordpress desiredStatus=STOPPED lastStatus=STOPPED taskDefinition="ECS-WORDPRESS:6"
INFO[0027] Stopped container...                          container=3f479b81-8c44-48c9-ac66-12d62828f19d/mysql desiredStatus=STOPPED lastStatus=STOPPED taskDefinition="ECS-WORDPRESS"

After we deploy the compose file, we can view the containers that are running on our cluster with the ecs-cli ps command:

$ ecs-cli ps --cluster wordpress
Name                                            State    Ports                      TaskDefinition   Health
ce7fc5a3-b8a4-4790-a762-3d455e5b755b/wordpress  RUNNING  34.236.237.178:80->80/tcp  ECS-WORDPRESS     UNKNOWN
ce7fc5a3-b8a4-4790-a762-3d455e5b755b/mysql      RUNNING                             ECS-WORDPRESS    UNKNOWN

We can see the wordpress and mysql containers from our compose file, and also the IP address and port of the web server. If we point a web browser to that address, we should see the WordPress installation wizard.

Modifies the number of container instances in our cluster. This command changes the desired and maximum instance count in the Auto Scaling group created by the ecs-cli up command. We can use this command to scale out (increase the number of instances) or scale in (decrease the number of instances) our cluster:

$ ecs-cli scale --capability-iam --size 2 --cluster wordpress

A Task launches containers that's defined in the task definition until they are stopped or exit on their own, at which point they are not replaced automatically. We can use Service to guarantee that we always have some number of tasks running at all times. If ECS container instance or Task's container fails the ECS Service will replace the failed Task.

Let's bring down the tasks and then run it as an ECS service to keep a desired count of 1:

To bring down the tasks:

$ ecs-cli compose down --cluster wordpress --cluster-config wordpress
INFO[0001] Stopping container...                         container=2ea5175d-e957-467e-8fd1-4b66d2a4a9c3/wordpress
INFO[0001] Stopping container...                         container=2ea5175d-e957-467e-8fd1-4b66d2a4a9c3/mysql
INFO[0001] Describe ECS container status                 container=2ea5175d-e957-467e-8fd1-4b66d2a4a9c3/wordpress desiredStatus=STOPPED lastStatus=RUNNING taskDefinition="ECS-WORDPRESS"
INFO[0001] Describe ECS container status                 container=2ea5175d-e957-467e-8fd1-4b66d2a4a9c3/mysql desiredStatus=STOPPED lastStatus=RUNNING taskDefinition="ECS-WORDPRESS"
INFO[0007] Stopped container...                          container=2ea5175d-e957-467e-8fd1-4b66d2a4a9c3/wordpress desiredStatus=STOPPED lastStatus=STOPPED taskDefinition="ECS-WORDPRESS"
INFO[0007] Stopped container...                          container=2ea5175d-e957-467e-8fd1-4b66d2a4a9c3/mysql desiredStatus=STOPPED lastStatus=STOPPED taskDefinition="ECS-WORDPRESS"

To run tasks as an ECS service:

$ ecs-cli compose service up --cluster wordpress --cluster-config wordpress
INFO[0001] Using ECS task definition                     TaskDefinition="ECS-WORDPRESS:10"
INFO[0001] Created an ECS service                        service=ECS-WORDPRESS taskDefinition="ECS-WORDPRESS:10"
INFO[0001] Updated ECS service successfully              desiredCount=1 force-deployment=false service=ECS-WORDPRESS
INFO[0017] (service ECS-WORDPRESS) has started 1 tasks: (task 860a2438-ee98-4a39-8898-4af1ca7c24c6).  timestamp="2018-12-22 20:11:07 +0000 UTC"
INFO[0033] Service status                                desiredCount=1 runningCount=1 serviceName=ECS-WORDPRESS
INFO[0033] ECS Service has reached a stable state        desiredCount=1 runningCount=1 serviceName=ECS-WORDPRESS

We can see a service is up and running:

Now, we can scale the tasks via service. So, to scale in the task to 0, we use the following:

$ ecs-cli compose service scale 0 --cluster wordpress --cluster-config wordpress

To keep the scale as 1, we need to down the service, and modify the memory_limit in ecs-params.yml. Then, up the service again.

$ ecs-cli compose service down --cluster wordpress --cluster-config wordpress
INFO[0000] Updated ECS service successfully              desiredCount=0 force-deployment=false service=ECS-WORDPRESS
INFO[0001] Service status                                desiredCount=0 runningCount=1 serviceName=ECS-WORDPRESS
INFO[0032] Service status                                desiredCount=0 runningCount=0 serviceName=ECS-WORDPRESS
INFO[0032] (service ECS-WORDPRESS) has stopped 1 running tasks: (task a8772c92-bc5a-4ffa-8d87-802a63facd8e).  timestamp="2018-12-22 20:41:55 +0000 UTC"
INFO[0032] ECS Service has reached a stable state        desiredCount=0 runningCount=0 serviceName=ECS-WORDPRESS
INFO[0032] Deleted ECS service                           service=ECS-WORDPRESS
INFO[0032] ECS Service has reached a stable state        desiredCount=0 runningCount=0 serviceName=ECS-WORDPRESS

$ ecs-cli compose service up --cluster wordpress --cluster-config wordpress
INFO[0001] Using ECS task definition                     TaskDefinition="ECS-WORDPRESS:11"
INFO[0001] Created an ECS service                        service=ECS-WORDPRESS taskDefinition="ECS-WORDPRESS:11"
INFO[0001] Updated ECS service successfully              desiredCount=1 force-deployment=false service=ECS-WORDPRESS
INFO[0017] Service status                                desiredCount=1 runningCount=1 serviceName=ECS-WORDPRESS
INFO[0017] (service ECS-WORDPRESS) has started 1 tasks: (task cf58034b-6b26-44b4-aa00-f9522c71ef33).  timestamp="2018-12-22 20:45:15 +0000 UTC"
INFO[0017] ECS Service has reached a stable state        desiredCount=1 runningCount=1 serviceName=ECS-WORDPRESS

We don't have to set service scale to 1 because it's the default:

ecs-cli compose service scale 1 --cluster wordpress --cluster-config wordpress

When we are done with this tutorial, we should clean up our resources so they do not incur any more charges. First, delete the service so that it stops the existing containers and does not try to run any more tasks.

Now, take down our cluster, which cleans up the resources that we created earlier with ecs-cli up:

$ ecs-cli down --cluster wordpress
Are you sure you want to delete your cluster? [y/N]
y
INFO[0003] Waiting for your cluster resources to be deleted... 
INFO[0004] Cloudformation stack status                   stackStatus=DELETE_IN_PROGRESS
INFO[0065] Cloudformation stack status                   stackStatus=DELETE_IN_PROGRESS
INFO[0132] Cloudformation stack status                   stackStatus=DELETE_IN_PROGRESS
INFO[0193] Deleted cluster                               cluster=wordpress

The command deleted the cloudformation with resources created and the cluster including our ecs instance.

Docker & K8s

1. Docker install on Amazon Linux AMI
2. Docker install on EC2 Ubuntu 14.04
3. Docker container vs Virtual Machine
4. Docker install on Ubuntu 14.04
5. Docker Hello World Application
6. Nginx image - share/copy files, Dockerfile
7. Working with Docker images : brief introduction
8. Docker image and container via docker commands (search, pull, run, ps, restart, attach, and rm)
9. More on docker run command (docker run -it, docker run --rm, etc.)
10. Docker Networks - Bridge Driver Network
11. Docker Persistent Storage
12. File sharing between host and container (docker run -d -p -v)
13. Linking containers and volume for datastore
14. Dockerfile - Build Docker images automatically I - FROM, MAINTAINER, and build context
15. Dockerfile - Build Docker images automatically II - revisiting FROM, MAINTAINER, build context, and caching
16. Dockerfile - Build Docker images automatically III - RUN
17. Dockerfile - Build Docker images automatically IV - CMD
18. Dockerfile - Build Docker images automatically V - WORKDIR, ENV, ADD, and ENTRYPOINT
19. Docker - Apache Tomcat
20. Docker - NodeJS
21. Docker - NodeJS with hostname
22. Docker Compose - NodeJS with MongoDB
23. Docker - Prometheus and Grafana with Docker-compose
24. Docker - StatsD/Graphite/Grafana
25. Docker - Deploying a Java EE JBoss/WildFly Application on AWS Elastic Beanstalk Using Docker Containers
26. Docker : NodeJS with GCP Kubernetes Engine
27. Docker : Jenkins Multibranch Pipeline with Jenkinsfile and Github
28. Docker : Jenkins Master and Slave
29. Docker - ELK : ElasticSearch, Logstash, and Kibana
30. Docker - ELK 7.6 : Elasticsearch on Centos 7
31. Docker - ELK 7.6 : Filebeat on Centos 7
32. Docker - ELK 7.6 : Logstash on Centos 7
33. Docker - ELK 7.6 : Kibana on Centos 7
34. Docker - ELK 7.6 : Elastic Stack with Docker Compose
35. Docker - Deploy Elastic Cloud on Kubernetes (ECK) via Elasticsearch operator on minikube
36. Docker - Deploy Elastic Stack via Helm on minikube
37. Docker Compose - A gentle introduction with WordPress
38. Docker Compose - MySQL
39. MEAN Stack app on Docker containers : micro services
40. MEAN Stack app on Docker containers : micro services via docker-compose
41. Docker Compose - Hashicorp's Vault and Consul Part A (install vault, unsealing, static secrets, and policies)
42. Docker Compose - Hashicorp's Vault and Consul Part B (EaaS, dynamic secrets, leases, and revocation)
43. Docker Compose - Hashicorp's Vault and Consul Part C (Consul)
44. Docker Compose with two containers - Flask REST API service container and an Apache server container
45. Docker compose : Nginx reverse proxy with multiple containers
46. Docker & Kubernetes : Envoy - Getting started
47. Docker & Kubernetes : Envoy - Front Proxy
48. Docker & Kubernetes : Ambassador - Envoy API Gateway on Kubernetes
49. Docker Packer
50. Docker Cheat Sheet
51. Docker Q & A #1
52. Kubernetes Q & A - Part I
53. Kubernetes Q & A - Part II
54. Docker - Run a React app in a docker
55. Docker - Run a React app in a docker II (snapshot app with nginx)
56. Docker - NodeJS and MySQL app with React in a docker
57. Docker - Step by Step NodeJS and MySQL app with React - I
58. Installing LAMP via puppet on Docker
59. Docker install via Puppet
60. Nginx Docker install via Ansible
61. Apache Hadoop CDH 5.8 Install with QuickStarts Docker
62. Docker - Deploying Flask app to ECS
63. Docker Compose - Deploying WordPress to AWS
64. Docker - WordPress Deploy to ECS with Docker-Compose (ECS-CLI EC2 type)
65. Docker - WordPress Deploy to ECS with Docker-Compose (ECS-CLI Fargate type)
66. Docker - ECS Fargate
67. Docker - AWS ECS service discovery with Flask and Redis
68. Docker & Kubernetes : minikube
69. Docker & Kubernetes 2 : minikube Django with Postgres - persistent volume
70. Docker & Kubernetes 3 : minikube Django with Redis and Celery
71. Docker & Kubernetes 4 : Django with RDS via AWS Kops
72. Docker & Kubernetes : Kops on AWS
73. Docker & Kubernetes : Ingress controller on AWS with Kops
74. Docker & Kubernetes : HashiCorp's Vault and Consul on minikube
75. Docker & Kubernetes : HashiCorp's Vault and Consul - Auto-unseal using Transit Secrets Engine
76. Docker & Kubernetes : Persistent Volumes & Persistent Volumes Claims - hostPath and annotations
77. Docker & Kubernetes : Persistent Volumes - Dynamic volume provisioning
78. Docker & Kubernetes : DaemonSet
79. Docker & Kubernetes : Secrets
80. Docker & Kubernetes : kubectl command
81. Docker & Kubernetes : Assign a Kubernetes Pod to a particular node in a Kubernetes cluster
82. Docker & Kubernetes : Configure a Pod to Use a ConfigMap
83. AWS : EKS (Elastic Container Service for Kubernetes)
84. Docker & Kubernetes : Run a React app in a minikube
85. Docker & Kubernetes : Minikube install on AWS EC2
86. Docker & Kubernetes : Cassandra with a StatefulSet
87. Docker & Kubernetes : Terraform and AWS EKS
88. Docker & Kubernetes : Pods and Service definitions
89. Docker & Kubernetes : Service IP and the Service Type
90. Docker & Kubernetes : Kubernetes DNS with Pods and Services
91. Docker & Kubernetes : Headless service and discovering pods
92. Docker & Kubernetes : Scaling and Updating application
93. Docker & Kubernetes : Horizontal pod autoscaler on minikubes
94. Docker & Kubernetes : From a monolithic app to micro services on GCP Kubernetes
95. Docker & Kubernetes : Rolling updates
96. Docker & Kubernetes : Deployments to GKE (Rolling update, Canary and Blue-green deployments)
97. Docker & Kubernetes : Slack Chat Bot with NodeJS on GCP Kubernetes
98. Docker & Kubernetes : Continuous Delivery with Jenkins Multibranch Pipeline for Dev, Canary, and Production Environments on GCP Kubernetes
99. Docker & Kubernetes : NodePort vs LoadBalancer vs Ingress
100. Docker & Kubernetes : MongoDB / MongoExpress on Minikube
101. Docker & Kubernetes : Load Testing with Locust on GCP Kubernetes
102. Docker & Kubernetes : MongoDB with StatefulSets on GCP Kubernetes Engine
103. Docker & Kubernetes : Nginx Ingress Controller on Minikube
104. Docker & Kubernetes : Setting up Ingress with NGINX Controller on Minikube (Mac)
105. Docker & Kubernetes : Nginx Ingress Controller for Dashboard service on Minikube
106. Docker & Kubernetes : Nginx Ingress Controller on GCP Kubernetes
107. Docker & Kubernetes : Kubernetes Ingress with AWS ALB Ingress Controller in EKS
108. Docker & Kubernetes : Setting up a private cluster on GCP Kubernetes
109. Docker & Kubernetes : Kubernetes Namespaces (default, kube-public, kube-system) and switching namespaces (kubens)
110. Docker & Kubernetes : StatefulSets on minikube
111. Docker & Kubernetes : RBAC
112. Docker & Kubernetes Service Account, RBAC, and IAM
113. Docker & Kubernetes - Kubernetes Service Account, RBAC, IAM with EKS ALB, Part 1
114. Docker & Kubernetes : Helm Chart
115. Docker & Kubernetes : My first Helm deploy
116. Docker & Kubernetes : Readiness and Liveness Probes
117. Docker & Kubernetes : Helm chart repository with Github pages
118. Docker & Kubernetes : Deploying WordPress and MariaDB with Ingress to Minikube using Helm Chart
119. Docker & Kubernetes : Deploying WordPress and MariaDB to AWS using Helm 2 Chart
120. Docker & Kubernetes : Deploying WordPress and MariaDB to AWS using Helm 3 Chart
121. Docker & Kubernetes : Helm Chart for Node/Express and MySQL with Ingress
122. Docker & Kubernetes : Deploy Prometheus and Grafana using Helm and Prometheus Operator - Monitoring Kubernetes node resources out of the box
123. Docker & Kubernetes : Deploy Prometheus and Grafana using kube-prometheus-stack Helm Chart
124. Docker & Kubernetes : Istio (service mesh) sidecar proxy on GCP Kubernetes
125. Docker & Kubernetes : Istio on EKS
126. Docker & Kubernetes : Istio on Minikube with AWS EC2 for Bookinfo Application
127. Docker & Kubernetes : Deploying .NET Core app to Kubernetes Engine and configuring its traffic managed by Istio (Part I)
128. Docker & Kubernetes : Deploying .NET Core app to Kubernetes Engine and configuring its traffic managed by Istio (Part II - Prometheus, Grafana, pin a service, split traffic, and inject faults)
129. Docker & Kubernetes : Helm Package Manager with MySQL on GCP Kubernetes Engine
130. Docker & Kubernetes : Deploying Memcached on Kubernetes Engine
131. Docker & Kubernetes : EKS Control Plane (API server) Metrics with Prometheus
132. Docker & Kubernetes : Spinnaker on EKS with Halyard
133. Docker & Kubernetes : Continuous Delivery Pipelines with Spinnaker and Kubernetes Engine
134. Docker & Kubernetes : Multi-node Local Kubernetes cluster : Kubeadm-dind (docker-in-docker)
135. Docker & Kubernetes : Multi-node Local Kubernetes cluster : Kubeadm-kind (k8s-in-docker)
136. Docker & Kubernetes : nodeSelector, nodeAffinity, taints/tolerations, pod affinity and anti-affinity - Assigning Pods to Nodes
137. Docker & Kubernetes : Jenkins-X on EKS
138. Docker & Kubernetes : ArgoCD App of Apps with Heml on Kubernetes
139. Docker & Kubernetes : ArgoCD on Kubernetes cluster
140. Docker & Kubernetes : GitOps with ArgoCD for Continuous Delivery to Kubernetes clusters (minikube) - guestbook