Definition of a Dockerfile to use bash scripts on a Windows 10 machine for our Cloud-Native-Starter workshop

We defined a Dockerfile to create a Docker image for our Cloud-Native-Starter workshop especially for Windows 10 users. The users can now simply create a Docker image on the local Windows 10 machine and then follow the guided steps in the hands-on workshop documentation and use the bash scripts. The reason why we don’t build a Docker image and share the image on Dockerhub is, we want to provide users the freedom of own customizations.

These are some challenges we had during the testing of the Dockerfile definition:

• File sharing for Docker images on Windows
• Docker port forwarding
• Docker in Docker
• Istio Virtual service configuration
• Linux tools missing

Why should we use a Docker image?

We wrote a lot of bash scripts to simplify the setup and steps inside the hands-on workshop. These bash scripts can’t be executed on a Windows console or in a Windows Power shell .

It is possible to install other environments like Cygwin on windows to use bash scripts, but we notice with that solutions, other problems do appear, related development tools installations. Marc from PCWDLD pointed me to a  guide/cheat sheet for using Cygwin. Maybe that’s could be useful for you.

We know that it is possible to install bash on Ubuntu on Windows 10, but we want to avoid such additional effort in a hands-on workshop for participants, who maybe will come unprepared to the workshop.

The Dockerfile solution decision

We decide to use a Docker image on Windows and define our own Dockerfile using Ubuntu as a starting point. The reason why we don’t  build a Docker image and share it on Dockerhub  is we want to provide the freedom of own customization for the users and we can add the file with no effort to our GitHub project, and the users will always build a actual Docker image with the newest tools.

Use of the Docker image

With the Docker command

docker run -ti my-workshop-image:v1

we can start the Docker image in the interactive mode in a terminal session on our  Windows 10 machine.

In the image below we see the start of the Docker image and the verification of the installed prerequisites of the workshop on the Docker image.

It seems that’s the best solution for our Windows 10 users to setup their machines in our workshop. They only need is to install Docker on Windows 10, which is effortless.

Installation of the developer and Linux tools

We need to install developer tools on our Docker image, as documented in our workshop and some missing or useful Linux tools.

That are the developer tools we need to install into the Docker image:

• Git
• CURL
• Docker (CLI only)
• IBM Cloud CLI and two specific packages
• kubectl from Kubernetes

In the Dockerfile definition, we see Ubuntu is our starting point for the Docker image and the needed/useful Linux tools:

FROM ubuntu

RUN apt-get update
RUN apt-get --assume-yes install curl
RUN apt-get --assume-yes install git-core
RUN apt-get --assume-yes install wget
# editor
RUN apt-get --assume-yes install nano
# setup network tools
RUN apt-get --assume-yes install apt-utils
RUN apt-get --assume-yes install net-tools
# zip
RUN apt-get --assume-yes install unzip
RUN apt-get --assume-yes install zip

File sharing for Docker images on Windows

It is challenging to share the local host filesystem on a Windows machine with a Docker image, because of the Windows Azure authorization. We search in the internet to get an easy solution, but the search ends with no easy solution. Here we see a long discussion in the Docker community about that topic.

With this in mind we decide just to clone our git repository into the Docker image, because that is the simplest way for our situation. Here we see how we clone our project.

# Cloud-Native-Starter -project
# https://github.com/IBM/cloud-native-starter/blob/master/workshop/00-prerequisites.md
# Install
RUN mkdir usr/cns
WORKDIR /usr/cns
RUN git clone https://github.com/IBM/cloud-native-starter.git
WORKDIR /usr/cns/cloud-native-starter

Docker in Docker

With the usage of the IBM Cloud Kubernetes service and the IBM Cloud Container Registry we don’t need to run the Docker daemon inside our docker image. So we can move on with the Dockerfile solution for the workshop. Inside our bash scripts we logon to IBM Cloud and we use the command ibmcloud cr build. Here we see the build command:

In the following image we see the difference between the usage of the IBM Cloud CLI and the Docker CLI.

With Docker CLI we can’t build the Docker image and with the IBM Cloud CLI we can build a container image.

The reason why we can build the container image is, we are logged on to the IBM Cloud and we use the IBM Cloud CLI to upload the build context  to the IBM Cloud Container Registry and we build the image inside the IBM Cloud Container Registry. With that situation we are able to avoid Docker in Docker usage, but we need the Docker CLI to be installed.  The image below, shows a simplified view, how it works in our situation on Windows 10.

Port forwarding

The last remaining problem is: How to do a port forwarding with Docker on windows that uses Hyper-V?

Normally we do a local port forwarding on a PC from our IBM Cloud Kubernetes cluster to access the Kiali with a local browser. That is the command:

kubectl -n istio-system port-forward $(kubectl
 -n istio-system get pod -l app=kiali -o jsonpath='{.items[0].metadata.name}') 20001:20001

But when we use this local port-forwarding inside the Docker image we can’t access the Kiali ui.

The reason is, we don’t have a browser inside our Docker image and even if we would install one, we can’t use command line and an open browser in our Docker image at the same time. Remember we are in an interactive terminal mode.

We must expose the port 20001 to our Docker image, to access Kiali in a browser on a local machine.  That is the command, we use to start the Docker image and expose the port 20001.

docker run -ti -p 20001:20001 my-workshop-image:v1

But we notice, we are not able to access Kiali in a browser on the local Windows system. The reason for this is, Hyper-V runs our Docker Linux and we only have exposed the port to that Linux in the Hyper-V.  If we want to access the port from the Windows host system, we need to expose the same port 20001 in Hyper-V.  That’s a too complex configuration for our workshop and we decide to use Virtual Service configuration with Istio on our Kubernetes cluster in IBM Cloud.

The image below shows a simplified view of our needed port forwarding/exposing.

Configuration of the  Virtual Service for Istio

To solve the port forwarding challenge, we decide to configure the Istio Virtual Service. We map the Kiali port directly in the Istio Virtual Service and with that configuration it is possible to access Kiali from our Kubernetes Cluster directly.

Therefor we define a match for Kiali using: uri, port and host information, as we see in the following YAML configuration.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtualservice-ingress-web-api-web-app
spec:
  hosts:
  - "*"
  gateways:
  - default-gateway-ingress-http
  http:
  - match:
    - uri:
        prefix: /kiali
    route:
    - destination:
        port:
          number: 20001
        host: kiali.istio-system.svc.cluster.local

With that configuration we access easily the Kiali ui directly on our free Kubernetes Cluster on IBM Cloud.

I hope this was useful for you and let’s see what’s next?

Greetings,

Thomas

PS: You can try out Cloud Foundry Apps or Kubernetes on IBM Cloud. By the way, you can use the IBM Cloud for free, if you simply create an IBM Lite account. Here you only need an e-mail address.

#ibmdeveloper, #ibmcloud, #cloudnativestarter, #cns, #istio, #kubernetes ,#youtube, #kiali, #windows, #docker, #dockerfile, #hyper-v, #ibmcloud-cli, #docker-cli