Devops

The config file contains the XML tags to enforce the security, you have to disable this option by changing it to false from true.

If you happen to forget your admin account jenkins password, Then you need to have the shell acccess to your jenkins setup
and modify config.xml and restart the jenkins service..
The passwords in jenkins are one way hash and they are encrypted using jbcrypt.

Lets look at a couple of ways to reset the password, first is disable to global security on jenkins server by modifying the /var/lib/jenkins/config.xml as shown below:
First method is to completely disable the security on Jenkins so that you can access the Jenkins without any password prompt, which means any body on the network can do so if they have the knowledge about it. Please advise caution.

[vamshi@linuxcent jenkins]$ sudo grep useSecurity -C1 /var/lib/jenkins/config.xml
<mode>NORMAL</mode>
<useSecurity>false</useSecurity>
<authorizationStrategy class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy">

Proceed to restart the jenkins service from commandline.

Login to the GUI and then update the password. These files contain the jenkins login information.

How to reset the user password of jenkins ?

The second method being directly modifying the jbcrypt hashed password present in the file /var/lib/jenkins/users/<Your UserName>/config.xml
For example:

[root@linuxcent jenkins]# grep password /var/lib/jenkins/users/admin_353942241645223362/config.xml
<passwordHash>#jbcrypt:$2a$10$razdYOUR-OLD-HASH.IVrFydsxkcQCcLmujmFQz12345678</passwordHash>

Now replace the jbcrypt hash code line with this
<passwordHash>#jbcrypt:$2a$10$uEbq9yc/UErlbO0BjqcaNutxTXueFcTkbad1jR9iOeOiNx5koRFi6</passwordHash>
and save the file. The decrypted password is admin and use this password for the next time login after restating jenkins service.

This process will come in real handy in case you forgot your jenkins login password
Alternately you can use this hash
#jbcrypt:$2a$10$razd3L1aXndFfBNHO95aj.IVrFydsxkcQCcLmujmFQzll3hcUrY7S — for a decrypted password called test

NOTE: This is only a hash is a simple temporary password to login to the jenkins and needs to be change to a stronger password

Now save the file /var/lib/jenkins/users/admin_353942241645223362/config.xml and restart the Jenkins server:

$ sudo systemctl restart jenkins

Now navigate to your Jenkins UI, enter your username and the password “admin” to login.
Once you are logged in make sure to navigate to http://jenkins.linuxcent.com:8080/user/admin/configure
eg: http://jenkins.linuxcent.com:8080/user/<Your Username>/configure

and Now enter a preferred new strong password and save the changes, You will be automatically logged out and then logback in with the new password.

How do I find my Jenkins admin password?

For this the Username is admin. Password should be located in: $JENKINS_HOME/secrets/initialAdminPassword.
You can view the password using: cat /var/lib/jenkins/secrets/initialAdminPassword.
cat $JENKINS_HOME/secrets/initialAdminPassword.

What is Jenkins default admin password?

Initializing Jenkins. The first time you start Jenkins, the configuration is created along with the administrator user and password. The default login is admin/password.

How do I find my username and password for Jenkins Windows?

• Copy the initialAdminPassword in Specified path.
• Login with following Credentials User Name : admin Password : <da12906084fd405090a9fabfd66342f0>
• Once you login into the jenkins application you can click on admin profile and reset the password.

How do I log into Jenkins without a password?

How to Reset Jenkins Admin User Password

• Enable “Enable Security’ option.
• In Security Realm option select “Jenkins own database”
• Make sure to uncheck “Allow users to sign up” option under the “Jenkins own database” option.
• Save Changes – Save all changes made above.

How do I change my Jenkins UI password?

Reset Jenkins Admin Password

Select the “Security Realm” (e.g. “Jenkins’ own user database” ) and click on “Save” Go to “People” -> Click on a username for which you want to change the password (e.g. admin ) -> “Configure” -> Enter a new password in the “Password” and “Confirm password” fields and click on “Save”

How do I create a Jenkins user and password?

• Steps to create a new user
• Login into Jenkins.
• Go to Manage Jenkins.
• Go to Create Users.
• Enter all the details – Username, Password, Confirm Pwd, FullName, Email.
• Select Create User.

How do I reset Jenkins to default?

• In config. xml , set disableSignup to false .
• Restart Jenkins.
• Go to the Jenkins web page and sign up with a new user.
• In config. …
• If it’s a private server, set disableSignup back to true in config. …
• Restart Jenkins.
• Go to the Jenkins web page and log in as the new user.
• Reset the password of the original user.

How do I restart Jenkins?

• Go to the Jenkins installation, open the cmd and run:
• To stop: jenkins.exe stop.
• To start: jenkins.exe start.
• To restart: jenkins.exe restart.

How do I unlock Jenkins?

• Unlocking Jenkins
• From the Jenkins console log output, copy the automatically-generated alphanumeric password (or) open the file located in /var/Jenkins_home/secrets/initialAdminPassword .
• On the Unlock Jenkins page, paste this password into the Administrator password field and click Continue.

How do I reset my Jenkins password on Mac?

• To Reset individual password:
• Go to /opt/bitnami/apps/jenkins/jenkins_home/users/gmhawash.
• Edit config. xml file.
• Remove the passwordHash tag (you can now log in without password)

Best practices while building the Dockerfile.

The context in Dockerfile is relative to the current working directory of the Dockerfile and that the location where Dockerfile is present becomes its context.

Which means we can create a Directory with some content and place our Dockerfile inside it and then traverse a number of directories away from the directory and can still execute the build command

Here is an example of out general approach to building an image from a Dockerfile with . context:

# docker build --tag nginx-linuxcent .

And we list the image as follows:

[vamshi@docker01 ~]$ docker images
REPOSITORY                                   TAG                 IMAGE ID            CREATED             SIZE
nginx-linuxcent                              latest              0b0a4ea4d48a        3 minutes ago      210.1 MB

The build context is a . dot and the Dockerfile is present in the same directory.
If You are working locally you don’t really need a repository name and specifying just the image name is sufficient and then adding a tag is considered optional, in such cases a latest tag is appended to the end of the newly build image

As a standard practice that the Dockerfile doesn’t traverse back from the current working directory. Lets see an demonstration of of building a Dockerfile by giving the relative path from its Dockerfile.

Example given:

[vamshi@node01 ~]$ ls nginx/
default.conf Dockerfile-nginx index.html nginx.conf Portal.tar.gz

Here is our nginx/Dockerfile-nginx.

cat Dockerfile-nginx
FROM nginx:1.17.2-alpine
COPY index.html /usr/share/nginx/html/
ADD Portal.tar.gz /tmp/new1/portal
CMD ["/usr/sbin/nginx"]

Our command to build this Dockerfile-nginx now becomes:

[vamshi@docker01 ~]$ docker build -t nginx-linuxcent -f nginx/Dockerfile-nginx nginx/
Sending build context to Docker daemon 155.4 MB
Step 1/4 : FROM nginx:1.17.2-alpine
---> 55ceb2abad47
Step 2/4 : COPY index.html /usr/share/nginx/html/
---> cc652d0fc2b7
Removing intermediate container 11f195a0e2ac
Step 3/4 : ADD Portal.tar.gz /tmp/new1/portal1/
---> b18a86545c47
Removing intermediate container 1e1849be08b4
Step 4/4 : CMD /usr/sbin/nginx
---> Running in fdac087b636b
---> 02e2795eab12
Removing intermediate container fdac087b636b
Successfully built 02e2795eab12

Or you can also mention the absolute path as shown below.

[vamshi@docker01 ~]$  # docker build -t nginx-linuxcent -f /home/vamshi/nginx/Dockerfile-nginx /home/vamshi/nginx/

The above example successfully builds a docker image. The Directory nginx/ is its build context as nginx/Dockerfile-nginx is the relative path of the input Dockerfile-nginx to docker build command.

Dockerfile and the context being different

Placing the Dockerfile-nginx inside the nginx directory and context placed one directory above the Dockerfile-nginx.

We now need to modify and carefully place the ADD/COPY commands relative to its directory in order for it to work properly, The context being one directory ahead, they should be prefixed with the directory name as we see below:

FROM nginx:1.17.2-alpine
COPY nginx/index.html /usr/share/nginx/html/
ADD nginx/Portal.tar.gz /tmp/new1/portal1/
CMD ["/usr/sbin/nginx"]

Now our docker build command takes the following syntax:

[vamshi@docker01 ~]$ docker build -t nginx-linuxcent -f nginx/Dockerfile-nginx .
Sending build context to Docker daemon 155.4 MB
Step 1/4 : FROM nginx:1.17.2-alpine
 ---> 55ceb2abad47
Step 2/4 : COPY nginx/index.html /usr/share/nginx/html/
 ---> Using cache
 ---> cc652d0fc2b7
Step 3/4 : ADD nginx/Portal.tar.gz /tmp/new1/portal1/
 ---> Using cache
 ---> b18a86545c47
Step 4/4 : CMD /usr/sbin/nginx
 ---> Using cache
 ---> 02e2795eab12
Successfully built 02e2795eab12

Here the context remains outside the directory and the Dockerfile is present inside the subdirectory, the ADD/COPY commands are prefixed with the relative path of the dubirectory

Common errors Encountered with context mismatch:

unable to prepare context: The Dockerfile must be within the build context

How to tag a Docker image with a repository name during build process?

You can name your Dockerfile anything and it doesnt matter to the build process as long as you refer it with the -f

The standard naming convention is as shown below.

# docker build -t <DOCKER_IMAGE-NAME>:<TAG> -f Dockerfile .

Syntax:

# docker build -t <REPOSITORY/REGISTRY NAME>/<DOCKER_IMAGE-NAME>:<TAG> -f Dockerfile .

# docker build --tag mydocker-registry-name/nginx-linuxcent:version1.0 -f Dockerfile .

Here the Dockerfile need not be explicitly mentioned with -f as the name of the file is Dockerfile and the context being .

# docker build --tag mydocker-registry-name/nginx-linuxcent:version1.0 - .

The Build context . at the end is important because it signifies the current context and the context cannot span backward.

The tag name is a must for best practices and helps in identifying the newly build images and tagging enables visible versioning and better identification of images.

Docker build with no-cache

Creating Docker images with the --no-cache option when you do not use cache when building the image, The default option for this is set to false and can be used explicitly to enforce no-cache..

It can be at times important when building container images which are dependent upon downloading latest libraries from the internet or practically from your on-premise code repository which contains the freshly compiled code artifacts.

Build the Docker image with no cache:

# docker build --no-cache -t mydocker-registry-name/nginx:version0.1 -f Dockerfile .

Once the docker container is successfully built, we can take a look at the newly created image as below.

# docker images

REPOSITORY                                       TAG                 IMAGE ID            CREATED             SIZE
mydocker-registry-name/nginx:                    version0.1          bcdd25553d01        3 minutes ago       298 MB

Conclusion:

The docker build context becomes the present path of the Dockerfile.The docker image build is a simple process if things are neatly organized and the context can be quiet tricky if you are managing multiple Docker builds. You have the flexibility to give the absolute of relative path to the docker build.
Its always advised to implement the relative path and use the . dot as context being in the same directory where your Dockerfile is present to run the Docker builds.

Ensure to use the no-cache option

And have a proper tagging in place to enable better version identity of your docker images.

If at all you need to build an image being in different context then always write the Dockerfile relative to the directory path of current context

What is build context Docker daemon?

The build context is the set of files located at the specified PATH or URL. Those files are sent to the Docker daemon during the build so it can use them in the filesystem of the image.

How do I put files outside Docker build context?

The best way to work around this is to specify the Dockerfile independently of the build context, using -f. For instance, this command will give the ADD command access to anything in your current directory. docker build -f docker-files/Dockerfile .

What is Docker context file?

The docker context command makes it easy to export and import contexts on different machines with the Docker client installed. You can use the docker context export command to export an existing context to a file. This file can later be imported on another machine that has the docker client installed.

What is Docker compose context?

Either a path to a directory containing a Dockerfile, or a url to a git repository. When the value supplied is a relative path, it is interpreted as relative to the location of the Compose file. This directory is also the build context that is sent to the Docker daemon.

What can you do with Docker compose Yml?

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.

How do I launch a Docker daemon?

On MacOS go to the whale in the taskbar > Preferences > Daemon > Advanced. You can also start the Docker daemon manually and configure it using flags. This can be useful for troubleshooting problems. Many specific configuration options are discussed throughout the Docker documentation.

Can you have multiple Dockerfiles?

Docker Compose is the most common way to build an application that uses multiple Dockerfiles. This requires a YAML file to create the container based on a series of commands.

What is difference between ADD and copy in Dockerfile?

COPY takes in a src and destruction. It only lets you copy in a local or directory from your host (the machine-building the Docker image) into the Docker image itself. ADD lets you do that too, but it also supports 2 other sources. First, you can use a URL instead of a local file/directory.

Does Docker copy follow symlinks?

That is not possible and will not be implemented. Please have a look at the discussion on github issue #1676: A symlink on your machine is the not the same as my machine and the same Dockerfile would produce two different results.

What is the Docker daemon?

The Docker daemon ( dockerd ) listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes. A daemon can also communicate with other daemons to manage Docker services.

Cannot connect to the docker daemon at unix:///var/run/docker.sock. is the docker daemon running?

The above error is very common in docker as there any many factors that cause this and we will see the practical use cases of then and the explanation with solutions.

Firstly the socket file is the main Unix/Linux pipe that is used by the dockerd which provides a self-sufficient runtime environment for the docker containers.

We generally come across the issues with the following error stating "Docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock” as the aprticular user executing docker cli is not authorized

We have a simple fix for this issue, As a Best practice on linux server running docker daemon, we need to update the following file /etc/sysconfig/docker with relevant docker group as shown below:

# /etc/sysconfig/docker

# Modify these options if you want to change the way the docker daemon runs
OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false -G dockerroot'

We have added the new Value of -G dockerroot to the OPTIONS= in /etc/sysconfig/docker
-G is the Flag to add the linux group and dockerroot is the privileged docker linux group for the docker daemon on centos/RHEL systems.
We now need to save the file and restart the docker daemon as we have modified the configuration file for the Docker daemon.

[vamshi@node01 ~]$ sudo systemctl restart docker

We now need to ensure the user accessing the docker command is part of the group dockerroot using usermod command as shown below.

[root@node01 ~]# sudo usermod -aG dockerroot vamshi

We now verify the user group information and verify the user is part of the group dockerroot.

[root@node01 ~]# id vamshi
uid=1001(vamshi) gid=1001(vamshi) groups=1001(vamshi),10(wheel),994(dockerroot)

You need relogin back if you are using the username to apply the linux group changes and once you login back you will be able to access the docker with the user account.

This process works for centos systems as we have modified the file /etc/sysconfig/docker and
The same approach can be implemented on Debian/Ubuntu systems by modifying /etc/default/docker which we will look at another post.

Now lets look at the second approach to the problem which is more of getting your hands dirty..
You will now modify the socket file by Hand as we will demonstrate in the following demonstration.

For us to be able to access this, we have to be have a read permission to this socket.
The permissions on /var/run/docker.sock will be as follows:

[vamshi@node02 ~]$ ls -l /var/run/docker.sock
srw-rw----. 1 root root 0 Apr 07 14:02 /var/run/docker.sock

As I mentioned earlier this being a socket file, as the symbol s is indicated at the start of the file permission attributes in the above output.

To overcome this issue, we have to create a docker group on the docker server as follows:

[vamshi@node02 ~]$ sudo groupadd docker

We check the group entity with the following command:

[vamshi@node02 ~]$ sudo getent group docker
docker:x:1009:

Now applying the docker group ownership to /var/run/docker.sock

[vamshi@node02 ~]$ sudo chgrp docker /var/run/docker.sock

And Here is the socket file attributes with updated group ownership:

[vamshi@node01 ~]$ ls -l /var/run/docker.sock 
srw-rw----. 1 root docker 0 Apr 07 14:09 /var/run/docker.sock

Now we have to add our user to the docker group to gain the rw permissions.
We do that in the following steps:

# sudo usermod -aG docker vamshi

Now we confirm the group members as below:

[vamshi@node02 ~]$ sudo getent group docker
docker:x:1009:vamshi

Now we need to logout and login back to this system and we will be able to access the docker command with the user.

The Other issues you might face while accessing the docker cli is probably accessing the docker server over a network where in the connection is established over the TCP connection with the docker server.

The docker server is also capable of handling the requests over the network provided it is exposed over a TCP port.
In most of the docker client server architecture, The Docker server listens on a tcp port over the network and This will be the second scenario where you have to access the docker server over the tcp socket and have to enable to the DOCKER_HOST with the docker server details over tcp.

You can try to connect to the docker server as follows

[user@docker-client ~]$ docker -H tcp://<Your-Docker-Server-IP>:<Port> version

Below is a practical command example:

[vamshi@jenkins-slave01 ~]$ docker -H tcp://10.100.0.10:4243 version

This scenario is most common with build agents like the jenkins slave and containers which run the post build and perform deployments. and is more common in the jenkins build environment..

The third most probable cause being that the actual docker server is not running if you have a local only setup and you can confirm by running the simple troubleshooting steps below by checking the process list and grep for docker process
ps -ef | grep docker and ensure that you have the docker services is started sudo systemctl status docker and ensure that its enabled on startup with sudo systemctl enable docker

Please refer our other Devops documents and do share your best practices in comments.

How do you fix Docker Cannot connect to the Docker daemon at Unix VAR run Docker sock is the Docker daemon running?

How to Resolve the “cannot connect to the Docker daemon” Error

1. Method 1: Check the Docker Engine.
2. Method 2: Assign Ownership to the Docker Unix Socket.
3. Method 3: Check the Ownership of Used Files.
4. Method 4: Add Your User to the Docker Group.
5. Method 5: Add Environment Tables on OS X.

How do I connect to a Docker daemon?

How to Connect to a Remote Docker Daemon

1. sudo mkdir -p /etc/systemd/system/docker.service.d.
2. sudo nano /etc/systemd/system/docker.service.d/options.conf.
3. [Service] ExecStart= ExecStart=/usr/bin/dockerd -H unix:// -H tcp://0.0.0.0:2375.
4. # Reload the systemd daemon.

How do I make sure Docker daemon is running?

Another way to check for a running Docker daemon is by inspecting its process ID file. The daemon writes its process ID to /var/run/docker. pid each time it starts up. When this file exists, Docker should be running and ready for CLI connections.

Is the Docker daemon running Docker in Docker?

Docker daemon by default listens to docker. sock. If you are on the same host where Docker daemon is running, you can use the / var/run/docker. … To run docker inside docker, all you have to do it just run docker with the default Unix socket docker.

Is the Docker daemon running MacOS?

On macOS the docker binary is only a client and you cannot use it to run the docker daemon, because Docker daemon uses Linux-specific kernel features, therefore you can’t run Docker natively in OS X.

What is Unix VAR run?

A new TMPFS-mounted file system, /var/run , is the repository for temporary system files that are not needed across system reboots in this Solaris release and future releases. For security reasons, /var/run is owned by root.

What is Unix VAR run Docker sock?

sock is basically the Unix socket the Docker daemon listens on by default. It is also a tool used to communicate with the Docker daemon from within a container. The image shows how container can access the features of docker daemon without being part of the interface itself.

What is Docker daemon and Docker?

Docker Daemon is simply a part of Docker Engine. Quoting the Docker engine overview page: Docker Engine is an open source containerization technology for building and containerizing your applications. Docker Engine acts as a client-server application with: A server with a long-running daemon process dockerd.

What is Docker daemon?

Docker daemon is a persistent background process that manages the containers on a single host. It is a self-sufficient runtime that manages Docker objects such as images, containers, network, and storage. … By default, Docker daemon creates a non-networked Unix domain socket at /var/run/docker.

How do I shutdown a docker daemon?

To stop the docker process that is already running you can just press ctrl + c or send a kill signal to it.

Where is Docker daemon port?

Check your Docker daemon. After restarting docker service, you can see the port in the output of systemctl status docker. service like /usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock

How to restart a docker container from commandline?

The docker command provides many options and one of them enables us to restart a container.

How to restart a running docker container?

[vamshi@node01 ~]$ docker restart jenkins_master01
jenkins_master01

We can set a wait timer using the -t[number in seconds] flag:

[vamshi@node01 ~]$ docker  restart -t20 jenkins_master01

[root@node01 ~]# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                 NAMES
c86791fad19c        jenkins             "/bin/tini -- /usr..."   42 minutes ago      Up 6 seconds        8080/tcp, 50000/tcp   jenkins_master01

How to start a docker container?

# docker start <container-id | container-name>

We look at a practical example, listing out the exited container as follows:

[vamshi@node01 ~]$ docker ps -f status="exited"  | grep jenkins -B1
CONTAINER ID        IMAGE                                        COMMAND                  CREATED             STATUS                     PORTS               NAMES
b511234ebe31        rrskris/jenkins                            "/bin/tini -- /usr..."   3 weeks ago         Exited (143) 1 day ago                       jenkins_master01

We now will start the container back live as follows:

[vamshi@node01 ~]$ docker start b511234ebe31 
b511234ebe31

It did not complain and lets check the running status again now:

[vamshi@node01 ~]$ docker ps -f status="running"  | grep jenkins -B1
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                 NAMES
b511234ebe31        rrskris/jenkins   "/bin/tini -- /usr..."   3 weeks ago         Up 9 minutes        8080/tcp, 50000/tcp   jenkins_master01

It did start alright and carried on the same old name and preserved its old state

How to build a docker image from scratch using its root file system?

We will be demonstrating the custom docker image build by using the linux debian Distribution’s rootfs.

Our workstation environment is Debian Buster, which will be used to build a debian docker Image from a same distro linux rootfs.

Lets get our environment upto speed and download the necessary build tool for our project.

We need the command debootstrap which gives the necessary build tools to go ahead.

$ wget http://ftp.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.116_all.deb

from your debian/ubuntu apt repository you can install as shown below:

# apt-get install debootstrap

Install the debootstrap package on the Host workstation.

$ sudo dpkg --install debootstrap_1.0.116_all.deb

To Neatly organize our build directory we can create a directory where we can download the rootfs.

$ sudo mkdir /tmp/debian-build

Downloading the debian rootfile system

Now we begin our process by looking up the Debian latest rootfs and running it against the debootstrap as shown below.

$ sudo debootstrap stable [BUILD-DIR] http://deb.debian.org/debian/

And also you can really explicit and filter some specifics as follows and choose a specific variant of debian OS as shown below.

$ sudo debootstrap --variant=minbase --components=main,contrib --include=dirmngr,apt-transport-https --arch=amd64 buster debian-buster http://deb.debian.org/debian/

Now you can also append the –verbose flag to print the background information.

Once you have successfully downloaded the rootfs, you can then verify the directory, which is /tmp/debian-build build directory in our case.

$ ls /tmp/debian-build

chroot-ing to the build directory

Now we need to chroot into the [BUILD-DIR] as follows

$ sudo chroot /tmp/debian-build

Now please note how the PS! prompt changes are you are chrooted to the latest build directory.

root@node03:/# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@node03:/# pwd
/

Now we are chroot-ed into our Debian build directory and our main goal is to remove as many unneeded packages as possible to downsize the image.

We now need to follow some best practices to implement and configure the build.

Firstly we create a file /etc/apt/apt.conf.d/10-assume_yes, as shown below which auto assumes the apt commands.
And run the below commands to remove the packages.

# echo "APT::Get::Assume-Yes \"true\";" | tee /etc/apt/apt.conf.d/10-assume_yes
# apt-get remove --purge -y $(apt-mark showauto) && rm -rf /var/lib/apt/lists/*
# apt-get autoremove -y
# apt-get clean
# apt-get remove --allow-remove-essential e2fsprogs e2fslibs nano pinentry-curses whiptail kmod iptables iproute2 dmidecode
# apt-get clean

We should now exit of the chroot environment by typing exit

With this you will be left with the total size of around 160MB.

root@node03:~# du -sh /tmp/debian-build
164M /tmp/debian-build

Once we are satisfied with the rootfs contents we proceed to the next steps to accomplish our goal of building a docker image.

Processing the rootfs directory into a tar file.

# sudo tar --verbose --create --file archive-name.tar --directory [BUILD-DIR] .

In our case the [BUILD-DIR] is debian-build directory.

# sudo tar --verbose --create --file debian-vamshi.tar --directory debian-build .

Creating a Docker image from the tar file

# cat archive.tar | sudo docker import - [Docker-image-name]

# cat debian-vamshi.tar | sudo docker import - debian-vamshi

Once the import operation is successfully completed we are left with a pure debian docker image to be used up.

By Successfully Stripping down the debian Image, I finally ended up with 178MB size of of debian image.

$ docker images
docker-repo/debian-vamshi        latest                  f57963009dd8        About a minute ago        178MB

Thus the process of debian image stripdown and creation of a docker image.
The same process applies to the Ubuntu linux distro, which will be discussed in another post.

The docker provides some in-house monitoring tools to extract the runtime information.

docker top is one such command.

[root@node01 ~]# docker top [container-id | container-name]

Here is the output of the docker top command.

[root@node01 ~]# docker top admiring_torvalds 
UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
centos              13169               13153               0                   10:43               ?                   00:00:00            /bin/tini -- /usr/local/bin/jenkins.sh
centos              13191               13169               9                   10:43               ?                   00:00:21            java -jar /usr/share/jenkins/jenkins.war

When you try to see the stats of an exited container it shows up with an error as follows as the container is not running

[vamshi@node01 ~]$ docker top exited_container
Error response from daemon: Container 31b8ab84a175ce79b03ba1c9608e9d358db45f74914407212b0d2c7744324806 is not running

The docker also provides a stat command which prints out the current docker image stats
The syntax:
# sudo docker stats [CONTAINER ID | CONTAINER NAME]

This is demonstrated as follows:

CONTAINER ID        NAME                   CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
73caf780c813        do-nothing-container   0.00%               996KiB / 471.5MiB   0.21%               2.08kB / 0B         4.81MB / 0B         1

Kubernetes is a Orchestration mechanism for running your container infrastructure on linux based machines.
In this tutorial we will be looking at the server based kubernetes installation on centos7 linux server OS.

Installing the kubernetes minimum requirements

Have 2 CPU cores with 2 GB or more RAM.

Have the swap memory disabled.

The swap memory can be disabled using the swapoff -a command.

Now, Lets take a look at the prerequisites to perform a kubernetes installation:

The Docker as the runtime container engine.
We make sure that the docker is already installed on the system.

[root@node01 ~]# docker --version
Docker version 1.13.1, build b2f74b2/1.13.1

Ensure you are loggedin as the root user to the machine to perform the remaining procedure.
We now start of the Kubernetes installation by adding the yum repo as demonstrated below:

STEP 1:

[root@node01 ~]# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
> [kubernetes]
> name=Kubernetes
> baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
> enabled=1
> gpgcheck=1
> repo_gpgcheck=1
> gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
> EOF

Now update the repositories with yum update command:

# yum update
-- OUTPUT TRUNCATED --
kubernetes/signature                                                                                                                             |  454 B  00:00:00     
Retrieving key from https://packages.cloud.google.com/yum/doc/yum-key.gpg
Importing GPG key 0xA7317B0F:
 Userid     : "Google Cloud Packages Automatic Signing Key <[email protected]>"
 Fingerprint: d0bc 747f d8ca f711 7500 d6fa 3746 c208 a731 7b0f
 From       : https://packages.cloud.google.com/yum/doc/yum-key.gpg
Is this ok [y/N]: y
Retrieving key from https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
-- OUTPUT TRUNCATED --

Till this step the repository addition is complete.

STEP2:

We now Hop onto the proposed Kubernetes master server, proceed with setup of the kubenetes master and Container cluster management components..
Downloading the kubernetes master and the kubernetes network interface binaries to configure the kubernetes master.
The yum package manager offer the following components which have to installed as dependencies to configure the kubernetes-master.

We should do some configuration before hand to enable the bridging net.bridge.bridge-nf-call-iptables

Enabling the bridging on the master node by adding the following to /etc/sysctl.d/kubernetes.conf. Create this file under /etc/sysctl.d

[root@node01 ~]# cat /etc/sysctl.d/kubernetes.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1

Or else we might run into errors like the one as follows:

[ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables contents are not set to 1

Now run the below command to read the new bridging rules.

# sysctl --system

Disabling SELINUX on the kubernetes master

We need to ensure the selinux is disabled for the purpose of simplifying the installation, You may encounter many cases where the selinux context obstructing the kublet to send the information to the kube-controller and kube-scheuler

[vamshi@node01 ~]$ sudo setenforce 0

Setting it to 0 using setenforce will set the selinux to permissive mode, and Verify it with the getenforce will display the results.

[vamshi@node01 ~]$ sudo getenforce 
Permissive

To make the SELINUX rules persistent across the reboot you need to modify its configuration file

[root@node01 ~]# sed -i 's/SELINUX=enabled/SELINUX=disabled/' /etc/selinux/config 
[root@node01 ~]# cat /etc/selinux/config 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

STEP3

Now lets shift our focus onto the Kubernetes and see the following core components of Kubernetes:

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• kubelet
• kube-proxy

 

We shall now beign installing kubeadm and kubernetes-cni

# yum install kubeadm kubernetes-cni

Here we have marked the kubernetes-cni because of the network components which goes along well with the kubernetes network scope management.

The important component is kubeadm which presides over the kubernetes cluster initialization.
To access the kubernetes we need the we need to install the kubectl, Although It will installed along with kubernetes-client package and if required can be install with the following command:

# yum install kubectl

 

STEP 4: Your Kubernetes worker Node

This is exclusive for the worker nodes which will be connected to the working kubernetes master.
STEP 1 is required to setup on the worker node so we can install and configure the kubernetes-node binary.
We will download the kubernetes-node Binaries from the yum package manager.

# yum install kubernetes-node kubernetes-client

STEP 5: Enabling the Full potential on the control-plane

The important step to enable and start the core kubernetes master services.
Here are the core important kubernetes services in the control-plane.

 kube-apiserver
 kube-controller-manager
 kube-scheduler

The Below services contributes on the data-plane or the worker-nodes and are also important on the contol-plane

 kubelet
 kube-proxy

The important configuration files on the kubernetes master:

• /etc/kubernetes/manifests

• /etc/kubernetes/pki

The important config files are:

• /etc/kubernetes/admin.conf

• /etc/kubernetes/kubelet.conf

• /etc/kubernetes/bootstrap-kubelet.conf

• /etc/kubernetes/controller-manager.conf

• /etc/kubernetes/scheduler.conf

The stateful data directories in Kubernetes are as below:

• /var/lib/etcd

• /var/lib/kubelet

• /var/lib/dockershim

• /var/run/kubernetes

• /var/lib/cni

 

Now we initialize the kubernetes with kubeadm as we see as follows:

kubeadm init --apiserver-advertise-address [preferred-master-node-ip-address|FQDN]

With the kubernetes successfully configured as follows you can begin digging deep onto the setup.

[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 10.100.0.10:6443 --token 123jei.123456783n6o8bq \
    --discovery-token-ca-cert-hash sha256:12345678906bff25a6d132a539e87321833181

Upon the successful installation you should see the following information with the client and the server version information:

Copy the kubeconfig file from the path /etc/kubernetes/config to the desired home directory under .kube/config

[root@node01 ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.1", GitCommit:"4485c6f18cee9a5d3c3b4e523bd27972b1b53892", GitTreeState:"clean", BuildDate:"2019-07-18T09:18:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-19T16:32:14Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

STEP 6: Initialize the Networking in Kubernetes

Here we enable the kubernetes networking with the preferred network provider:

kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml

We should be able to get the nodes

[root@node01 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
master.linuxcent.com Ready master 3h7m v1.18.2

Common Errors during the setup:

There can be some common errors during the installation I have faced and able to reproduce them in-order to find a quick resolution.

The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)
[E0509 9645 kubelet_node_status.go:92] Unable to register node

If you encounter the above error, then please ensure the following things:
Ensure that you have the kubelet service running,
The selinux is in disabled state. and then reinitialize, kubeadm reset and then kubeadm init command.

There may be errors related to the DNS not functioning:

Warning  FailedScheduling    default-scheduler  0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Then it definetly needs to apply the kubernetes networking plugin, please choose the calico or Weavenet or your preferred network plugin and apply those components.

The Dockerfile is a very simple to understand format containing of Statements often referred to as Docker DSL(Domain Specific Language), It tends to become quiet complex and difficult to understand over the time.

[vamshi@docker01 ~]$ cat Dockerfile

# Dockerfile which runs a Latest Ubuntu image and sleeps for 100 seconds
FROM ubuntu:18.04
LABEL maintainer="vamshi" version="1.0.0" description="My First Docker Image"
RUN apt-get update && apt-get dist-upgrade -y && apt-get autoremove -y && apt-get install -y tomcat
RUN apt-get remove --purge -y $(apt-mark showauto) && rm -rf /var/lib/apt/lists/*
WORKDIR /data
ENTRYPOINT ["sleep", "100"]

Let’s examine the Dockerfile and the Statements as follows:

The First line starting with # is a comment.
The Second line with FROM tag determines the image and the latest tag; .
Eg:

FROM ubuntu:latest FROM ubuntu:18.04 or FROM centos:7

The LABEL is a Descriptive tag and contains the information about the original author credits
RUN command simulates a shell command and the subsequent statements are executed as a shell command inside the container.
WORKDIR determines the  directory context inside the running container.
ENTRYPOINT is the invocation of the container main process which runs when the docker container runs and its failure to run means the termination or the end of the particular container.
From the above Dockerfile you would have noticed 2 formats of Instruction, Now lets discuss them in details:
Shell Form
The instructions are written as shell commands

RUN apt-get update , this in turn is formatted as bin sh -c “apt-get update” and enables for command expansion, inclusion of the special characters and it enables combining of multiple commands.

Exec Form
It is JSON array style
These instructions are also shell commands but they are represented in the form of elements in a list.

["command-name","arg1","arg2"]

This format has the following drawbacks
Here the shell is not provided
No scope for variable expansion and
also this format doesn’t allow the special characters like (&&, ||, >….) to be included into the command expression statements.

While running the docker container, the CMD takes the run time arguments and the JSON list format works as a preventive measure.

Advantage of CMD and ENTRYPOINT using square bracket JSON array notation

The most advantageous point with CMD or ENTRYPOINT being written in JSON list format is the during the container runtime, the CMD can take certain arguments which can alter the main container process.. and Thus we can shield against variable expansion, Injecting special characters and not providing a shell as a counter measure security practice.

How to build a Dockerfile?

From the current working directory navigate to the location where Dockerfile is present and run the below command.

# docker build --tag first-docker-image -f Dockerfile .

How to extract Build description from docker image?

We are able to extract the docker LABEL description and MAINTAINER information from the docker command which will help in identifying its purpose when have some hundreds of docker images.

[vamshi@node01 ~]$ docker image inspect first-image --format='{{.Config.Labels}}'
map[description:My First Docker Image maintainer:vamshi version:1.0.0]

Best Practices while building Docker images.

• While writing the Dockerfile, Its a good practice to include the version information.
• Include the description of the image which can be easily understood while inspecting the docker image from the inspect command.

• Grouping RUN shell commands together with && which are inter-dependent and relevant. The Docker by design stores a single STATEMENT as One Layer Image. This will enable better compressing and storing of docker image layers. This technique is called cache-busting.

  RUN apt-get update && apt-get dist-upgrade -y

• Its a good practice to cleanup the installed package sources and build files which lightens up the size of docker image layer.

  RUN apt-get autoremove -y && rm -rf /var/lib/apt/lists/*

• The Docker statements can be grouped together that have require less to no modification to save the network bandwidth and increase the docker build time.

The endpoints in kubernetes are the mechanism that directly interact and implement the Kubernetes Service

The Endpoints are underlying mechanism which are created in the background and enable us to talk to the kubernetes Services.
As we know that by creating a Kubernetes service we automatically generate the FQDN with the help of core-dns services

There was a requirement for me to setup the specific endpoint and create a service to convert a outside IP into the kubernetes FQDN [svc-name.namespace.cluster.local]
I managed to work around it by creating an endpoint of my external IP which was running mySQL.

[root@master01 ~]# cat Mysql-ep.yaml 
---
kind: Endpoints
apiVersion: v1
metadata:
 name: mysql-svc
 namespace: actoneye
subsets:
 - addresses:
     - ip: 172.22.110.130
   ports:
     - port: 3306

Lets take a look at Kubernetes Service yaml file.

[root@master01 ~]# cat Mysql-svc.yaml

---
kind: Service
apiVersion: v1
metadata:
 name: mysql-svc
spec:
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306

The mysql FQDN mysq-svc.dev.cluster.local was used in my application code for my cluster which the mysql resource was outside the kubernetes cluster.

Please try this out and let me know if you had any similar experiences to share.

How to Inject Variables into Docker image in build time without modifying the Dockerfile

 

We have a requirement wherein we need to modify the specific Dockerfile with the build information and we make use of string replace operations like SED to modify the data in Dockerfile, But we can make use of the docker build time arguments to achieve the results efficiently.

Here’s a snippet of Dockerfile

FROM ubuntu:17.04
LABEL maintainer="vamshi" version="1.0.0" description="JRUBY Docker image"
WORKDIR /app
ARG JRUBY_VER 9.2.11.1
ENV JRUBY_VER ${JRUBY_VER}
ADD https://repo1.maven.org/maven2/org/jruby/jruby-dist/${JRUBY_VER}/jruby-dist-${JRUBY_VER}-bin.tar.gz .

We now build this Dockerfile as follows passing the –build-arg:

# docker build --build-arg JRUBY_VER=9.2.8.0 -t jruby:v2  -f ./Dockerfile .

Here we have passed in the build arguments of –build-arg the JRUBY_VER=9.2.8.0 and this then assigns the Argument to the ENV and passed it to ADD command which downloads tar.gz.

When run the command without any build-args it readsup the predefined ARG JRUBY_VER 9.2.11.1 from the Dockerfile.

Conclusion:
Another best usecase is while you have a continuous Docker build pipeline system and want to pass the build time arguments on user input, Its best to use ARG statements inside while writing your Dockerfile

The Docker Environment variables can be declared during the (1) Docker image creation inside the Dockerfile and (2) During the docker container run time.

The Dockerfile ENV syntax is shown as follows:

ENV VAR_NAME value

We will look at the Dockerfile syntax in the following snippet:

# Exporting the Environment Variables
ENV MAVEN_HOME /usr/share/maven/
ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/
# Added as per Java team
ENV JAVA_OPTS -Xms256m -Xmx768m

We can even reference the ENV variable after the declaration at the next statement.

RUN ${JAVA_HOME}/bin/java -version

Conclusion:

Setting the ENV is a lot better than Hard coding the values into the Dockerfile, as it makes maintaining the Dockerfile a simpler task.

Its a good practice for storing the path names, version of packages which are set to be modified over a longer course of time.