How to Execute Shell Script from Dockerfile

Recently I faced a problem with Docker build. Before we build the image there was a requirement to cleanup something from MongoDB. For that we tried to create shell script and execute it from Dockerfile before we start the service. Here in this blog I will explain how you can execute the shell script from Dockerfile. 

For that first create the shell script in the same context of Dockerfile. That means the file should be in the same folder or subfolder where Dockerfile is there. 

We can not access file outside the Docker build context so file has to be in the same folder.

nano test.sh

You can put your content in this file for the tasks you want to do with this file. 

Now first we will copy the file in docker build context. So that it can be executed. This step is mandatory or else it will not find file. Add following lines of code in your Dockerfile.

FROM alpine3.15

COPY test.sh ./test.sh

Next step we have to change access rights of the script so it can be executed.

RUN chmod +x ./test.sh

Now since we have file in the Docker build context and it has proper access rights we can execute the file. 

RUN sh ./test.sh

That's it and now when to service starts it will execute the file and do all the actions which you have added in shell script.

Hope this helps you. 

Kubernetes ImagePullBackOff error

Recently I faced an issue while working Kubernetes cluster. I was trying to build docker image from local repository to test some changes in production before we merge the code. After building the docker image and recreating the container it was showing ImagePullBackOff error when I check the status with 

kubectl get pods

In this blog I am going to mention the possible cause for this error and will explain the resolution which worked for me.

In a Kubernetes, there’s an agent on for node which is called kubelet. This is responsible for running containers in the nodes. For some reason if image can't be pulled the kublet will throw ImagePullBackOff error. 

There are some possible reasons for this when kubectl is not able to pull image from mentioned registry. 

Either image or tag is not available. 

The name of the image or tag is wrong in deployment yaml file

kubectl does not have access to image registry. 

In my case there was no such issues mentioned above. The image with tag was there. I have specified the correct name in deployment yaml file and because it was a local registry, there was no need of authentication. 

So here is how I solved this issue. I set image pull policy to following value in my deployment yaml file.

imagePullPolicy: IfNotPresent

The reason it worked is, the kubectl was trying to find image in registry but it was not present because it was local registry so then it tried to find image in local repository and caches it. 

This solution worked for me because I was using local registry. If you are facing such issue try setting above value to imagePullPolicy and it may work. Hope this helps you.

Docker MongoDB terminates when it runs out of memory

When you have multiple services running in docker container it's quite possible that you have an issues with certain services when your docker container runs out of memory. MongoDB is one such service. 

On docker container when you have MongoDB running and when it starts storing huge data it starts consuming lots of memory and that's where you have an issue. MongoDB will crash after sometime where isn't much memory left. 

The reason behind this is the IO model of MongoDB, it tries to keep as much data as possible in cache so read and write operations are much faster. But this creates an issue with docker as we have limited memory and lots of services are sharing that. 

Starting from MongoDB 3.2 on words WiredTiger storage engine is the default one for MongoDB and it's recommended. 

There are various advantages of WiredTiger storage engine. For example,

• Document Level Concurrency
• Snapshots and Checkpoints
• Journal
• Compression
• Memory Use

One of most useful feature is Memory use. 

With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.

You can control it with --wiredTigerCacheSizeGB configuration.

The --wiredTigerCacheSizeGB limits the size of the WiredTiger internal cache. The operating system will use the available free memory for filesystem cache, which allows the compressed MongoDB data files to stay in memory. In addition, the operating system will use any free RAM to buffer file system blocks and file system cache.

With this setting you can enhance memory usage. MongoDB will not use excessive memory and with heavy data usage on docker container MongoDB will not crash on excessive memory usage.

Hope this helps you.