Forem: Phuong Hau

How I expose my applications on Kubernetes with Ingress and a domain

Phuong Hau — Sat, 28 Dec 2019 03:20:07 +0000

My intention of writing this post is to share with you things that I learned today and hope that might help some guy on the Internet just like me searching for a quick way to do something rather than reading a lot of dry text.

Motivation

The demand emerges when there is a fact that I have multiple applications running on my Kubernetes cluster, I have only one domain though. That is where Kubernetes Ingress resource comes into play.

Prerequisites

For the sake of simplicity and focusing on Ingress resource, I will assume that you are familiar with Kubernetes resource objects like: Deployment, Service,... and having control over your cluster with kubectl.

Let's do it

For demonstration purpose, I am going to spin up two applications, portfolio and healthinsight respectively. To achieve that, I simply create two deployments with one replica each, and also two services in order to keep track of IP of the pods created and destroy frequently.
If not mentioned otherwise, all resources are deployed on default namespace.

Yaml file for portfolio app

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: portfolio
  namespace: default
spec:
  selector:
    matchLabels:
      run: portfolio
  template:
    metadata:
      labels:
        run: portfolio
    spec:
      containers:
      - image: gcr.io/phuong-devops/portfolio:v2
        imagePullPolicy: IfNotPresent
        name: portfolio
        ports:
        - containerPort: 3000
          protocol: TCP
      imagePullSecrets:
      - name: gcr-key
---
apiVersion: v1
kind: Service
metadata:
  name: portfolio
  namespace: default
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    run: portfolio
  type: NodePort

YAML file for healthinsight app

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: healthinsight-app
  namespace: default
spec:
  selector:
    matchLabels:
      run: healthinsight-app
  template:
    metadata:
      labels:
        run: healthinsight-app
    spec:
      containers:
        - image: gcr.io/phuong-devops/healthinsight-frontend:v1
          name: healthinsight-app
          ports:
            - containerPort: 80
              protocol: TCP
      imagePullSecrets:
        - name: gcr-key
---
apiVersion: v1
kind: Service
metadata:
  name: healthinsight-app
  namespace: default
spec:
  ports:
  - port: 3001
    protocol: TCP
    targetPort: 80
  selector:
    run: healthinsight-app
  type: NodePort

Deploying these two applications is easy as a piece of cake.

The problem is our application is unreachable from the external network (Internet), so I deploy an Ingress resource on our Kubernetes cluster so as to it routes the traffic from Internet to our pods (applications).
Keep in mind that you have to setup an Ingress Controller to satisfy Ingress Resource. Only creating Ingress Resource below has no effect.

There are a bunch of Controller that may fit your preferences, take a look at here. For demonstration purpose, I will pick Nginx Ingress Controller, you could easily have your Nginx controller installed on your cluster after following the official documentation here

So what exactly Ingress do?

Ingress exposed HTTP and HTTPS routes from outside the cluster to services within cluster. Traffic routing is controlled by rules defined on the Ingress resource.

An Ingress can be configured to give Services externally-reachable URL, load balance, terminate SSL/TLS, and offer name based virtual hosting.

The below diagram illustrates our implementation.

I am going to deploy our Ingress resource configured to satisfy above demand.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: "nginx"
  name: cluster-ingress
  namespace: default
spec:
  rules:
  - host: hi.phuonghau.com
    http:
      paths:
      - backend:
          serviceName: healthinsight-app
          servicePort: 3001
  - host: phuonghau.com
    http:
      paths:
      - backend:
          serviceName: portfolio
          servicePort: 3000

Check out if our Ingress resource deployment works fine.

DNS

It is just not enough, we need to explicitly configure our domain DNS to navigate to our server cluster IP.

Note:
When we expose our applications on cluster on a domain name, we need the external IP address of an application to be static that does not change. So that the domain can correctly navigate to our clusters.

I am using GoDaddy for example, the steps are not the same if you are using other domain broker services, but the terms is applicable.

To reiterate, I want phuonghau.com to points to portfolio service and hi.phuonghau.com to point to health insight service.

Simply add an A record pointing to cluster IP (phuonghau.com points to clusterIP), and a CName hi points to phuonghau.com. Check the brief differences between an A record and Cname at here

It could take couple of minutes for your DNS configuration propagate over global.

Tadaaa

Now we can access multiple services on our Kubernetes cluster with only one domain.

Conclusion

With Kubernetes Ingress we are able to expose many applications to outside on the Internet with ease, those above steps is basically describe practical steps. The official document still the best place which we should take a glance at. Any feedback on this article is more than welcome.Thanks for reading.

How the Unix Shell sees the world (Expansion, Quoting)

Phuong Hau — Thu, 19 Dec 2019 16:17:09 +0000

TL;DR

It was me using Unix terminal every single day, typing hundred lines of terminal command, but sometimes, I encounter some unexpected behaviors at the moment I press Enter button after a command. It's pretty frustrated at some points, it turns out that the way the Shell sees the world is different than mine. I read some books (at least some chapters) about how the Shell acts upon a command, I find out it's really interesting so that I share with you today. Hope this helpful.

Because this is pretty straightforward. With only echo command, we can examine several interesting features, the "magic" of the Shell

The Expansion

Every time we press enter after a command, it get transformed by the Shell under the hood before get carried out. The process that makes it happen is call expansion. The expansion is that when you type in something, it get expanded to another thing before the shell acts upon it. For example: The * means a lot to the Shell. To illustrate this, I will use the echo command, as you recall that echo is a simple Shell built-in function that directs our typing to standard output

phuong@Arch ~$ echo Hello world
Hello world

So the * wildcard means: Match any characters in file-name. The fact that the * get transformed into other characters before being carried out by the shell so that the echo command never see the *

phuong@Arch ~/kitchen$ echo *
bash  device  devops  gateway  go  hook  iuh  js  linux  ml  python

Filename expansion

In fact, this behavior carried out by a mechanism, which is popularly called path name expansion. As we know, file names begin with period character (ex: .git) is hidden. The path name extension respect this rule. An expansion does not reveal hidden files.

phuong@Arch ~$ echo D*
Desktop Documents Downloads

But we can show all hidden files by following command:

phuong@Arch ~$ echo .*
. .. .3T .ansible .anydesk .bash_history .bash_logout .bash_profile .bashrc .bashrc.backup .boto .cache .config .dbshell .designer .docker

Arithmetic expansion

We are also able to use our terminal command as a calculator thanks to arithmetic expansion, but this it only works with simple integers (We need tools like bc,... for float numbers). In spite of its limitation, it might useful in some scenarios, it also supports many popular operators. Let's say: , -, *, %, /, +,...
Arithmetic expansion follows below pattern:

$((expression))

phuong@Arch ~$ echo This month has $((4*7)) days
This month has 28 days

As an alternative to double parentheses, we can also use single parentheses to nest sub expansion. Such as:

phuong@Arch ~$ echo This year has $((((4*7)*12) + $((3 * 9)))) days
This year has 363 days

Tilde expansion

When we using ~ as the beginning of the string in terminal, it expands to home directory of named user.
Let's say, I am using an account on the cloud where there are many users there and I don't known where their home directory are, I just know usernames of them. That is where it come into play

phuong@devcloud1:~$ echo ~wingzero
/home/wingzero
phuong@devcloud1:~$ echo ~phuong
/home/phuong

Brace expansion

The brace expression itself may contain either a comma-separated list of strings or a range of integers or single characters.

For the comma-separated example:

phuong@Arch ~/kitchen/ips$ echo A{A,B}
AA AB

Similarly, the range of single characters

phuong@Arch ~$ echo {A..Z}
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

From my point of view, this kind of expansion is one of the most interesting expansion mechanisms as it is pretty useful in specified situations. Suppose that I want to create each folder for each network IP in the subnet range. Pretending that 192.168.43.1 -> 192.168.43.13. So I confess the way that I would do 4 months a go is that: mkdir .... But this approach is prone to typo errors. So that is where the brace expansion comes and saves.

phuong@Arch ~/kitchen/ips$ mkdir 192.168.43.{1..13}
phuong@Arch ~/kitchen/ips$ ls
192.168.43.1   192.168.43.12  192.168.43.3  192.168.43.6  192.168.43.9
192.168.43.10  192.168.43.13  192.168.43.4  192.168.43.7
192.168.43.11  192.168.43.2   192.168.43.5  192.168.43.8

It is true as you may guest that the brace expansion can also be nested.

phuong@Arch ~/kitchen/ips$ echo A{a{1,2},b{9,10}}
Aa1 Aa2 Ab9 Ab10

Command substitution

Beside above expansion mechanisms, the command substitution maybe the one that you might feel familiar with because its widely used in scripting. The command substitution allows us to use the output of a command as an expansion. For instance:

phuong@Arch ~/kitchen$ ls -l $(which go)
lrwxrwxrwx 1 root root 18 Nov  2 17:25 /usr/bin/go -> /usr/lib/go/bin/go

Here is another example

phuong@Arch ~$ echo Hello $(w=world; echo $w)
Hello world

Parameter substitution

This kind of substitution is intensively used in scripting than directly in command line. For simple example, you want to print USER variable, you just add dollar symbol($) at the beginning.

phuong@Arch ~$ echo $USER
phuong

Note that if you mistyping the name of a variable, the expansion will still take place, but it results into empty string.

For the sake of simplicity, I will not go into detail. Because this powerful mechanism deserve another post for it. The scope of this post is to point out some popular expansion mechanisms and how to control them.

Quoting

So we have seen how powerful the expansion in the Shell is, that is why it could lead to some unexpected behaviors unless we know how to control it.
Now we come to interesting part.

Consider two samples below:
Example 1:

phuong@Arch ~$ echo Hello I am a          string
Hello I am a string

Example 2:

phuong@Arch ~$ echo It costs me $200
It costs me 00

Feel familiar ah?

In the first example, the word splitting ditches extra white spaces from the echo command's list of arguments. In the second example, the $2 is expanded by parameter expansion mechanism, that is on purpose, the problem is $2 variable is undefined so the Shell suppress unexpected expansion which finally leads to how it behaves. Let's figure out how to fix this.

Double Quotes

If you put special characters into double quotes will lost their special meanings to the Shell, but there are 3 exceptions for that, namely dollar sign, backslash and back tick.

This is pretty useful in specified scenario. To show you what I mean, imagine that one of your friends send you a homework file named "homework part1.doc". Well, that might drive you crazy.

Which leads you to below situation

phuong@Arch ~/Downloads$ cat homework part1.doc 
cat: homework: No such file or directory
cat: part1.doc: No such file or directory

The double quotes comes to save you.

phuong@Arch ~/Downloads$ mv "homework part1.doc" homework_part1.doc 
phuong@Arch ~/Downloads$ cat homework_part1.doc 
This is my stupid homework part, now is your turn

Once double quotes are added , our command contains a command followed by a single argument. That is how we preserve our extra white spaces, because world splitting mentioned above only take effect for multiple parameters. With everything putted in double quotes, it behave like only one parameter following the echo command

phuong@Arch ~/Downloads$ echo Hello I am a          string
Hello I am a string
phuong@Arch ~/Downloads$ echo "Hello I am a          string"
Hello I am a          string

Single quote

If you simply need to suppress all special characters, just use single quote

phuong@Arch ~/Downloads$ echo 'cat ~/Download/.doc {a,b} $(echo bar) $((3+2)) $USER'
cat ~/Download/.doc {a,b} $(echo bar) $((3+2)) $USER

Escaping characters

Sometimes we want to quote only a single character, to do this, just preceding that character with a backslash \

phuong@Arch ~/Downloads$ echo "You own me $30"
You own me 0
phuong@Arch ~/Downloads$ echo "You own me \$30"
You own me $30

It's common to selectively prevent the expansion of a filename.

Conclusion

To summarize, the expansion mechanisms in Unix Shell is great and powerful. If we know how to control it, I believe those features surely enhance your productivity. If you have any question, feel free to drop a comment below, that would be nice to hear from you.

Thanks for your time.

References

The Linux Command Line - William E. Shotts JR.

Yet another way to containerize your React app with Docker multi-stage build

Phuong Hau — Sat, 14 Dec 2019 15:20:37 +0000

TL;DR

In cloud computing world, an containerized application promotes the decoupling principle, which offers a logical packaging mechanism. It allows container-based applications to be easily deployed and ensures the consistency. As a React enthusiast, I am going to share with you yet another way how I package my React application.

Preparation

For the following steps, i assume that you have some basic knowledge of Docker, React, Linux-based folder structure...

Let's start

Init our React application

For convenience's sake, I init a blank React application with create-react-app.

phuong@Arch ~/kitchen/js$ npx create-react-app fooapp

Build our application using node:alpine image

We will use a NodeJS image in order to build application to guarantee complete isolation. After application to our application folder (in this case it is cd fooapp). Create a file named Dockerfile like below:

FROM node:alpine as builder
WORKDIR /app
COPY . ./
RUN npm install
RUN npm run build

Line 1: We declare the image that we use to build our React app and attach builder label to it.
Line 2: We use WORKDIR directive to indicate that we are currently in /app in container
Line 3: Copy our application into Docker container
Line 4: Install dependencies for our React application in container
Line 5: Execute command to build our application, our application will be built into chunk and saved in a directory named build

Serving our application using Nginx

But wait, it is true that our built application obviously cannot serve itself, we need a server to serve application as static resource. I recommend nginx image as our server because of its popularity for low resource consumption, simple configuration and high performance.
We need a configuration file for nginx server, let's create nginx.conf in your root of application folder:

server {
    listen       80;
    server_name  localhost;
    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
        try_files $uri /index.html;                 
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

In order not to copy node_modules and unwanted folders into our container. We simply list them in .dockerignore file

.git
node_modules
build

So our complete Dockerfile will be:

FROM node:alpine as builder
WORKDIR /app
COPY . ./
RUN npm install
RUN npm run build

FROM nginx:alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Line 7: Directive FROM indicates we use nginx:alpine image (in conjunction with node:alpine image)
Line 8: We copy nginx configuration file into our container
Line 9: --from=builder instructs docker to copy built folder from stage 1 as we labeled it above
Line 10: Expose port 80 to outside of the container
Line 11: Directive tell that nginx should stay in the foreground. Because for containers, it is useful as best practice is one process = one container.

Wrap everything up

Let's check our directory, we should have exact application directory like below.

Let's start building our container using command:

docker build -t fooapp:v1 .

Our build process

To verify everything is fine, we run our newly built container using command:

docker run --rm -d 8080:80 fooapp:v1

The --rm flag tells docker to remove the container after running our application container and -d instructs docker to bind port 80 on our host machine to port 8080 of our application container.

Voilà

Now we should be able access our application from browser.

For conclusion, I would like to thank you for your time reading my first post, above steps and arguments are just my personal thoughts, if there is anything wrong, let me hear from you. Feel free to drop comment below. Thanks. :)

P.s: I also published my git repo for this post at

phuonghau98 / dockerized-react-app

My dev.to reference docs:

https://dev.to/phuonghau98/yet-another-way-to-containerize-your-react-app-with-docker-multi-stage-build-3n6

View on GitHub