Web app deployment inside of Kubernetes with microk8s

based on the Kubernetes course:

 

1) install microk8s: sudo snap install microk8s

2) enable registry & dns: microk8s.enable registry dns

MONGODB deployment & service

3) configure the mongodb deployment

generate 2 secrets using md5sum from shell

MONGO_INITDB_ROOT_USERNAME=--insert_here_encrypted_username-- -e MONGO_INITDB_ROOT_PASSWORD=--insert_here_encrypted_password-- -e MONGO_INITDB_DATABASE=admin

4) apply the MongoDB database deployment and service

microk8s.kubectl apply -f mongodb-deployment.yaml

5) check the environment variables inside the container

5.1) enter inside the deployment:

microk8s.kubectl exec -it deployment.apps/mongodb-deployment sh

5.2) env

6.1) get inside the mongodb container:

from Docker: docker exec -it mongo bash

from Kubernetes: microk8s.kubectl exec -it mongodb-deployment--insert_your_deployment_id -- /bin/sh

6.2) authenticate to the mongodb database container:

mongo -u insert_here_encrypted_username -p insert_here_encrypted_password --authenticationDatabase admin

Our application deployment & service

7) build the docker image of our application:
docker build . -t localhost:32000/mongo-app:v1
8) test the image using port forwarding:
docker run -p 3000:3000 localhost:32000/mongo-app:v1

or: docker run  -it --rm -p 3000:3000 localhost:32000/mongo-app:v1

9) push the image into the kubernetes registry
docker push localhost:32000/mongo-app:v1

10) apply our custom application: microk8s.kubectl apply -f mongo.yaml

11) check whether the IP addresses of the service and pods match. This means that the service endpoints are correctly set and math the created pods:

microk8s.kubectl describe service
microk8s.kubectl get pod -o wide

Congratulations!

Permissions inside and outside of Docker containers

References: Docker for web developers course.

1) In Dockerfile, when building a container:

Inside the Dockerfile we can fix the container directory permissions: chown -R www-data:www-data /var/lib/nginx ->in order to let nginx to function properly

volumes & not empty dir -> files are copied from the dir to volume

bind mount & not empty dir -> if there are files they stay, nothing is being copied from the bind mount point

2) In docker-compose.yml

- volumes (volume:/var/lib/myslq) inherit the permissions and ownership from the user created the image - usually root.

- bind mounts (/my/own/datadir:/var/lib/mysql) - the permissions and ownership are the same as the directory on your host.

Even if in the Dockerfile we have: USER node or in docker-compose is specified user: "node:node", the local directory will be mounted preserving its UID:GID in the container, ignoring the USER directive.

Special case: when doing bind-mount and the uid in container != uid on host:

Solution is to change the ownership of the local dir before building the container and creating the bind with the same user/group: chown -R www-data:www-data /var/lib/nginx
There is a catch: when local uid <> container uid in the container then we will have mismatched permissions. We can solve this problem using UID/GID synchronization:

// optional

Check the user running the container from the dockerhub image: USER directive.
id -u

Check the container user to which group belongs (find its UID)
cat /etc/passwd | grep nevyan

id, groups, grep nevyan /etc/group

// end optional

1) Check the user which runs the server inside the container

ps aux | grep apache(server_name)

2) When having proper UID:GID, we again use chown but this time not with user/group names, but with UID:GUIDs

MySQL example: By default the MySQL image uses a non-root user with uid=1001. If we try to bind mount a local /var/lib/mysql (MySQL data directory not owned by UID 1001), to a non-root docker container - this will fail. Since user 1001 (from the container) needs to perform read/write operations to our local directory.

Solution: change the local directory permissions with numeric UID/GID expected by the container: sudo chown -R 1001 /my/own/datadir