Docker : Slack Chat Bot with NodeJS on GCP Kubernetes

In this post, we'll learn how to make a Slack chat bot using NodeJS. First, we need to make an account (channel) on Slack, and then run it on GCP with Dockerfile. Then, after uploading a Docker image to a public DockerHub, we'll deploy it to Kubernetes engine, and we'll also update the app later.

First, we will need to create a Slack account so our bot can interact with it. If already have a Slack account that skip to the next Section.

1. In a new browser tab, go to www.slack.com.

2. Enter e-mail id in the box and click GET STARTED.

3. Click Create a new workspace.

4. Check email, and use the confirmation code to confirm our account.

5. For What’s the name of company or team?, enter the company name and click Next.

6. For What’s a project our team is working on?, enter the project name details and click Next.

7. For Who else is working on this project?, click skip for now.

8. Click See Your Channel in Slack.

Configure Incoming WebHooks for Slack

An incoming webhook is an easy way to send Slack notifications from another service or app without having to worry about a persistent connection for two-way communication like with a bot user.

9. Sign into the Slack account.

10. In the navigation menu on the left, click Apps.

11. In the Browse Apps Search box, type

12. Click Install.

13. Click Add Configuration.

14. Click the Post to Channel drop-down and select #general.

15. Click Add Incoming WebHooks integration.

16. Copy the Webhook URL to a text editor.

We will need this later.

19. Scroll to the bottom, then click Save Settings.

20. Leave this browser tab/window open, we will return to it later.

Now we'll work directly in the Slack app.

A bot user can listen to messages on Slack, post messages, and upload files. We will create a bot post message - a simple greeting.

Create a new Slack app

1. Open the Slack apps management page in a new tab.

2. Click the Create New App button in the upper-right corner.

3. Name the app "Kittenbot".

4. Choose the Slack team where we want it installed.





5. Click Create App.

Add a new bot user to the app

1. Under Features in the left menu, select Bot Users.

2. Click the Add a Bot User button.

3. Our default name will be "kittenbot", use this.

4. In this post, we'll use the Realtime Messaging (RTM) API, so keep the Always Show My Bot as Online option Off. The bot user will show as online only when there is a connection from the bot.





5. Click the Add Bot User button.

Get the bot user OAuth access token

1. Select OAuth & Permissions in the left-hand menu.

2. Click Install App to Workplace. Click Authorize to confirm.





3. Click the Copy button to copy the Bot User OAuth Access Token text into our clipboard. We'll use the token in the next step. Don't worry. We can come back this configuration page from the apps management page if we need to get this token again.

Google Cloud Shell is loaded with development tools and it offers a persistent 5GB home directory and runs on the Google Cloud. Google Cloud Shell provides command-line access to our GCP resources. We can activate the shell: in GCP console, on the top right toolbar, click the Open Cloud Shell button:

In the dialog box that opens, click "START CLOUD SHELL".

gcloud is the command-line tool for Google Cloud Platform. It comes pre-installed on Cloud Shell and supports tab-completion.

Set our zone:

$ gcloud config set compute/zone us-central1-f
Updated property [compute/zone].

Clone the GitHub repository:

$ git clone https://github.com/googlecodelabs/cloud-slack-bot.git

$ cd cloud-slack-bot/start

Install the Node.js dependencies, including Botkit:

$ npm install

Throughout this post, we'll only work on the start directory.

Let's edit the kittenbot.js file and enter our Slack bot token. We can get it from the bot custom integration configuration page, and replace your-slack-token with the Slack token we copied:

var Botkit = require('botkit')

var controller = Botkit.slackbot({debug: false})
controller
  .spawn({
    token: 'xoxb-561163093201-566367619910-X5wJoYT0ekZihZDYRjtsNeVF' // Edit this line!
  })
  .startRTM(function (err) {
    if (err) {
      throw new Error(err)
    }
  })

controller.hears(
  ['hello', 'hi'], ['direct_message', 'direct_mention', 'mention'],
  function (bot, message) { bot.reply(message, 'Meow. :smile_cat:') })

In Cloud Shell run our bot:

$ node kittenbot.js
Initializing Botkit v0.7.0
info: ** No persistent storage method specified! Data may be lost when process shuts down.
****************************************************************************************
* WARNING: Your bot is operating without recommended security mechanisms in place.     *
* Initialize your Botkit controller with a clientSigningSecret paramter to enable      *
* verification that all incoming webhooks originate with Slack:                        *
*                                                                                      *
* var controller = new Botkit.slackbot({clientSigningSecret: }); *
*                                                                                      *
****************************************************************************************
>> Botkit docs: https://botkit.ai/docs/readme-slack.html#securing-outgoing-webhooks-and-slash-commands
>> Slack docs: https://api.slack.com/docs/verifying-requests-from-slack
notice: ** BOT ID: kittenbot ...attempting to connect to RTM!
notice: RTM websocket opened

We may see errors in Cloud Shell, but they won't affect the outcome. It's OK to keep going.

We should now see that kittenbot is online in our Slack team. We may need to refresh our browser.

Do the following to interact with it:

1. Click on the + next to Direct Messages:



2. Choose kittenbot, then click Go.
3. Type "hi" or "hello" to kittenbot! Kittenbot should meow back at us:

We hard-coded the Slack token in the source code. But makes it likely to accidentally expose our token by publishing it to version control or embedding it in a docker image. Instead, use Kubernetes Secrets to store tokens.

We will now write our token to a file (slack-token). This filename is in the .gitignore to prevent accidentally checking it in to version control.

Create a new file in the start directory called slack-token file.

Copy our token from kittenbot.js or the bot configuration page, paste it into the slack-token file, then Save.

Edit the kittenbot.js file to load the Slack token specified by the slack_token_path environment variable.

var Botkit = require('botkit')
var fs = require('fs') // NEW: Add this require (for loading from files).

var controller = Botkit.slackbot({debug: false})

// START: Load Slack token from file.
if (!process.env.slack_token_path) {
  console.log('Error: Specify slack_token_path in environment')
  process.exit(1)
}

fs.readFile(process.env.slack_token_path, function (err, data) {
  if (err) {
    console.log('Error: Specify token in slack_token_path file')
    process.exit(1)
  }
  data = String(data)
  data = data.replace(/\s/g, '')
  controller
    .spawn({token: data})
    .startRTM(function (err) {
      if (err) {
        throw new Error(err)
      }
    })
})
// END: Load Slack token from file.

controller.hears(
  ['hello', 'hi'], ['direct_message', 'direct_mention', 'mention'],
  function (bot, message) { bot.reply(message, 'Meow. :smile_cat:') })

Go back to the Cloud Console and run our bot:

$ slack_token_path=./slack-token node kittenbot.js

We should see the bot online again in Slack and be able to chat with it. After testing it out, press Ctrl-c to shut down the bot.

Now we want to containerize our bot. A Docker image bundles all of our dependencies so that it can run in a lightweight sandbox.

First, create a file called Dockerfile.

Then add the following definition, which describes how to build our Docker image.

FROM node:10.14
COPY package.json /src/package.json
WORKDIR /src
RUN npm install
COPY kittenbot.js /src
CMD ["node", "/src/kittenbot.js"]

A Dockerfile is a recipe for a Docker image. On top of the Node.js base image on the Docker hub, it copies package.json to the image and installs the dependencies listed in it, copies the kittenbot.js file to the image, and tells Docker that it should run the Node.js server when the image starts.

Go back to the Cloud Shell and build the image by running the docker build command.

$ docker build -t dockerbogo/slack-chat-bot:v1 .
Sending build context to Docker daemon  101.1MB
Step 1/6 : FROM node:10.14
10.14: Pulling from library/node
54f7e8ac135a: Pull complete
d6341e30912f: Pull complete
087a57faf949: Pull complete
5d71636fb824: Pull complete
0c1db9598990: Pull complete
89669bc2deb2: Pull complete
680b586c807d: Pull complete
16f1b885efe0: Pull complete
Digest: sha256:09dedfecd09e55b5b39ca9f04c40b1b70889a0b65d2de4d9d510d39b1a213c5f
Status: Downloaded newer image for node:10.14
 ---> 8a752d5af4ce
Step 2/6 : COPY package.json /src/package.json
 ---> 6309231e5e8c
Step 3/6 : WORKDIR /src
Removing intermediate container c9555587812a
 ---> 29dbfc6ae881
Step 4/6 : RUN npm install
 ---> Running in 1137745707e3
npm notice created a lockfile as package-lock.json. You should commit this file.
added 374 packages from 348 contributors and audited 7690 packages in 16.722s
found 0 vulnerabilities

Removing intermediate container 1137745707e3
 ---> 67eb5d5ca26c
Step 5/6 : COPY kittenbot.js /src
 ---> 49cc3e08fb8c
Step 6/6 : CMD ["node", "/src/kittenbot.js"]
 ---> Running in 3862155d9758
Removing intermediate container 3862155d9758
 ---> 5890f861c11a
Successfully built 5890f861c11a
Successfully tagged dockerbogo/slack-chat-bot:v1

In our Cloud Shell, let's test the Docker image locally with the following command. It will run a Docker container as a daemon from the newly-created container image:

$ docker run -d \
    -v $(pwd)/:/config \
    -e slack_token_path=/config/slack-token \
    dockerbogo/slack-chat-bot:v1

Note that the command also mounts the current directory as a volume inside the container to give it access to the slack-token file. We should see that kittenbot is online again.

Once tested, we may want to stop the container using docker stop CONTAINER_ID:

$ docker ps
CONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS              PORTS               NAMES
9a60c5b783cb        dockerbogo/slack-chat-bot:v1   "node /src/kittenbot…"   45 seconds ago      Up 44 seconds                           objective_thompson

$ docker stop 9a60c5b783cb
9a60c5b783cb

Now, it's time to push the Docker image to DockerHub repository from Cloud Shell:

$ docker login -u dockerbogo
Password:
Login Succeeded

$ docker push dockerbogo/slack-chat-bot:v1
The push refers to repository [docker.io/dockerbogo/slack-chat-bot]
278cf002e726: Pushed
5ab736f9f89c: Pushed
b2ad3d01092c: Pushed
98a57f3f2777: Mounted from library/node
...
v1: digest: sha256:e8bb6c6a36b35cbd72341ebb20278d3a2769c08666c670d6bad9740b692139cc size: 2634

In Cloud Shell, click the + button tab to add a new Cloud Shell session.

Go back to the incoming webhook we created. We can get back to there from the Slack Custom Integrations management console) and copy the webhook URL from the configuration page.

From the Incoming Webhooks page, get the sample curl under "Setup Instructions":

Run it from the shell. It will run curl to send an HTTP request with our message to Slack. Make sure the URL matches our webhook URL.

$ curl -X POST --data-urlencode "payload={\"channel\": \"#general\", \"username\": \"webhookbot\", \"text\": \"This is posted to #general and comes from a bot named webhookbot.\", \"icon_emoji\": \":ghost:\"}" https://hooks.slack.com/services/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
ok

We get this:

This demonstrates that anywhere that we can send an HTTP request, we can send a message to Slack. This is a really easy way to integrate our own apps and services with Slack notifications.

Now that the Docker image is in DockerHub Registry, we can run the docker pull command to save this image on any machine and run it with the Docker command-line tool.

If we want to make sure our bot keeps running after it is started, we'll have to run another service to monitor our Docker container to restart it if it stops. This gets harder if we want to make sure the bot keeps running even if the machine it is running on fails.

Kubernetes solves these problems. We tell it that we want there to always be a replica of our bot running, and the Kubernetes master will keep that target state. It starts the bot up when there aren't enough running, and shuts bot replicas down when there are too many.

A Kubernetes Engine cluster is a managed Kubernetes cluster. It consists of a Kubernetes master API server hosted by Google and a set of worker nodes. The worker nodes are Compute Engine virtual machines.

Return to the first Cloud Shell and create a cluster with two n1-standard-1 nodes:

$ gcloud container clusters create my-cluster \
      --num-nodes=2 \
      --zone=us-central1-f \
      --machine-type n1-standard-1
kubeconfig entry generated for my-cluster.
NAME        LOCATION       MASTER_VERSION  MASTER_IP     MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
my-cluster  us-central1-f  1.11.7-gke.4    35.239.123.8  n1-standard-1  1.11.7-gke.4  2          RUNNING

This command creates the cluster and authenticates the Kubernetes command-line tool, kubectl, with the new cluster's credentials.

Each node in the cluster is a Compute Engine instance provisioned with Kubernetes and Docker binaries and we can list all Compute Engine instances in our project:

$ gcloud compute instances list
NAME                                       ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
gke-my-cluster-default-pool-8533ff3b-j02f  us-central1-f  n1-standard-1               10.128.0.2   35.224.177.6    RUNNING
gke-my-cluster-default-pool-8533ff3b-w5mp  us-central1-f  n1-standard-1               10.128.0.3   35.224.180.185  RUNNING

First, we need to create a Secret in Kubernetes to store the Slack token and make it available to the container:

$ kubectl create secret generic slack-token --from-file=./slack-token
secret "slack-token" created

To deploy our containerized application to the Kubernetes cluster, we need to configure a Deployment, which describes how to configure the container and provide a replication controller to keep the bot running.

In the Cloud Shell Code Editor, create a file called slack-chat-bot-deployment.yaml:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: slack-chat-bot
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: slack-chat-bot
    spec:
      containers:
      - name: master
        image: dockerbogo/slack-chat-bot:v1  
                                                   
        volumeMounts:
        - name: slack-token
          mountPath: /etc/slack-token
        env:
        - name: slack_token_path
          value: /etc/slack-token/slack-token
      volumes:
      - name: slack-token
        secret:
          secretName: slack-token

Now we can create the Deployment by running kubectl create in Cloud Shell:

$ kubectl create -f slack-chat-bot-deployment.yaml --record
deployment.extensions "slack-chat-bot" created

Since we used the --record option, we can view the commands applied to this deployment as the "change-cause" in the rollout history:

$ kubectl rollout history deployment/slack-chat-bot
deployments "slack-chat-bot"
REVISION  CHANGE-CAUSE
1         kubectl create --filename=slack-chat-bot-deployment.yaml --record=true

See what the kubectl create command made. Re-run this command until the status shows Running:

$ kubectl get pods
NAME                              READY     STATUS    RESTARTS   AGE
slack-chat-bot-7c8dcbb696-rqhh4   1/1       Running   0          2m

Let's go to Slack, and see that kittenbot is back online.

Then, Say hello to kittenbot one last time in a direct message.

How do we deploy a new version of something that is already running on Kubernetes?

First, we need to modify the application. Botkit can handle conversations. With these, the bot can request more information and react to messages beyond a one word reply.

Edit the kittenbot.js file - add the following new kitten emoji delivery code to the bottom of the file:

// ...

// START: listen for cat emoji delivery
var maxCats = 20
var catEmojis = [
  ':smile_cat:',
  ':smiley_cat:',
  ':joy_cat:',
  ':heart_eyes_cat:',
  ':smirk_cat:',
  ':kissing_cat:',
  ':scream_cat:',
  ':crying_cat_face:',
  ':pouting_cat:',
  ':cat:',
  ':cat2:',
  ':leopard:',
  ':lion_face:',
  ':tiger:',
  ':tiger2:'
]

controller.hears(
  ['cat', 'cats', 'kitten', 'kittens'],
  ['ambient', 'direct_message', 'direct_mention', 'mention'],
  function (bot, message) {
    bot.startConversation(message, function (err, convo) {
      if (err) {
        console.log(err)
        return
      }
      convo.ask('Does someone need a kitten delivery? Say YES or NO.', [
        {
          pattern: bot.utterances.yes,
          callback: function (response, convo) {
            convo.say('Great!')
            convo.ask('How many?', [
              {
                pattern: '[0-9]+',
                callback: function (response, convo) {
                  var numCats =
                  parseInt(response.text.replace(/[^0-9]/g, ''), 10)
                  if (numCats === 0) {
                    convo.say({
                      'text': 'Sorry to hear you want zero kittens. ' +
                        'Here is a dog, instead. :dog:',
                      'attachments': [
                        {
                          'fallback': 'Chihuahua Bubbles - https://youtu.be/s84dBopsIe4',
                          'text': '!'
                        }
                      ]
                    })
                  } else if (numCats > maxCats) {
                    convo.say('Sorry, ' + numCats + ' is too many cats.')
                  } else {
                    var catMessage = ''
                    for (var i = 0; i < numCats; i++) {
                      catMessage = catMessage +
                      catEmojis[Math.floor(Math.random() * catEmojis.length)]
                    }
                    convo.say(catMessage)
                  }
                  convo.next()
                }
              },
              {
                default: true,
                callback: function (response, convo) {
                  convo.say(
                    "Sorry, I didn't understand that. Enter a number, please.")
                  convo.repeat()
                  convo.next()
                }
              }
            ])
            convo.next()
          }
        },
        {
          pattern: bot.utterances.no,
          callback: function (response, convo) {
            convo.say('Perhaps later.')
            convo.next()
          }
        },
        {
          default: true,
          callback: function (response, convo) {
            // Repeat the question.
            convo.repeat()
            convo.next()
          }
        }
      ])
    })
  })
  // END: listen for cat emoji delivery

We can test this out in Cloud Shell using the same command as before, but weu'll see two responses since the bot is still running in our Kubernetes cluster.

Next, build a new container image with an incremented tag (v2 in this case):

$ docker build -t dockerbogo/slack-chat-bot:v2 .
Sending build context to Docker daemon  101.1MB
Step 1/6 : FROM node:10.14
 ---> 8a752d5af4ce
Step 2/6 : COPY package.json /src/package.json
 ---> Using cache
 ---> 6309231e5e8c
Step 3/6 : WORKDIR /src
 ---> Using cache
 ---> 29dbfc6ae881
Step 4/6 : RUN npm install
 ---> Using cache
 ---> 67eb5d5ca26c
Step 5/6 : COPY kittenbot.js /src
 ---> d98d0354737c
Step 6/6 : CMD ["node", "/src/kittenbot.js"]
 ---> Running in e2539a74e45f
Removing intermediate container e2539a74e45f
 ---> 9c0c92f98058
Successfully built 9c0c92f98058
Successfully tagged dockerbogo/slack-chat-bot:v2

Push the image to DockerHub Registry:

$ docker push dockerbogo/slack-chat-bot:v2
The push refers to repository [docker.io/dockerbogo/slack-chat-bot]
b6df8616ab06: Pushed
e9f40fb0db24: Layer already exists
d6a459c0d824: Layer already exists
98a57f3f2777: Layer already exists
6bf27a21cb78: Layer already exists
4a6166f16a0e: Layer already exists
e02b32b1ff99: Layer already exists
f75e64f96dbc: Layer already exists
8f7ee6d76fd9: Layer already exists
c23711a84ad4: Layer already exists
90d1009ce6fe: Layer already exists
v2: digest: sha256:bf585cca4de3c1b0abb866c1ef1fdf26993cd661b0af458501a29b8d57287295 size: 2635

Building and pushing this updated image should be much quicker because now it's taking full advantage of caching.

As we did with the first version of the kitten bot, we can test locally using the node command and the docker command. We can skip those steps and push the new version to the cluster.

Now we're ready for Kubernetes to update the deployment to the new version of the application.

Edit the line in the slack-chat-bot-deployment.yaml file defining which image to use:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: slack-chat-bot
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: slack-chat-bot
    spec:
      containers:
      - name: master
        image: dockerbogo/slack-chat-bot:v2  
                                                   
        volumeMounts:
        - name: slack-token
          mountPath: /etc/slack-token
        env:
        - name: slack_token_path
          value: /etc/slack-token/slack-token
      volumes:
      - name: slack-token
        secret:
          secretName: slack-token

Now, to apply this change to the running Deployment, run the following command to update the deployment to use the v2 image: kubectl apply -f slack-chat-bot-deployment.yaml:

$ kubectl apply -f slack-chat-bot-deployment.yaml
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
deployment.extensions "slack-chat-bot" configured

Using the following command, we can monitor that Kubernetes has shut down the pod running the previous version and started a new pod that is running the new image:

$ kubectl get pods
NAME                              READY     STATUS    RESTARTS   AGE
slack-chat-bot-68d546bdf9-szlzx   1/1       Running   0          1m

It worth mentioning "deployment strategies". Since the deployment strategy was specified to "recreate" in the deployment, Kubernetes makes sure the old instances are shut down before creating a new one. This strategy is used because:

1. we don't mind a few seconds of downtime and
2. we don't want two custom integration bots running at the same time.

Alternatively, a rolling update strategy could have been used, which ensures that new versions are running before shutting down the old versions. This would be ideal if creating a Slack App used by multiple teams.

For more info about the strategy, please check:

1. Docker : Deployments to GKE (Rolling update, Canary and Blue-green deployments)
2. Docker : Continuous Delivery with Jenkins Multibranch Pipeline for Dev, Canary, and Production Environments on GCP Kubernetes.

To see the history:

$ kubectl rollout history deployment/slack-chat-bot
deployments "slack-chat-bot"
REVISION  CHANGE-CAUSE
1         kubectl create --filename=slack-chat-bot-deployment.yaml --record=true
2         kubectl create --filename=slack-chat-bot-deployment.yaml --record=true

We've just updated a Slack bot running on Kubernetes to a new version. Go back to Slack and type a message to kittenbot that mentions "kitten" and see it joining the conversation.

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