In continuation of my previous blog on “10. DevOps: How to Build images from Docker containers?”, I am continuing my lab exercises. In this session we can see ”
How to Launch a container as a daemon ?:“
Note: If you want to recollect the docker commands to be used during your current lab practice, visit my blog link:
Let us recap the past exercises; So far we have experimented with an interactive container, tracked the changes that were made to the containers., created images from the containers, and then gained insights in the containerization scenarios.
Now, let us see the container usage in a detached mode.
When we run the container in a detached mode it runs under a daemon process.
I want to use the “ubuntu” image and run detached mode command.
First, let me check my current docker images:
vskumar@ubuntu:~$ sudo docker images
[sudo] password for vskumar:
REPOSITORY TAG IMAGE ID CREATED SIZE
docker-exercise/ubuntu-wgetinstall latest e34304119838 7 days ago 169MB
<none> <none> fc7e4564eb92 7 days ago 169MB
hello-world latest f2a91732366c 12 days ago 1.85kB
ubuntu 16.04 20c44cd7596f 2 weeks ago 123MB
ubuntu latest 20c44cd7596f 2 weeks ago 123MB
busybox latest 6ad733544a63 4 weeks ago 1.13MB
busybox 1.24 47bcc53f74dc 20 months ago 1.11MB
You can see my previous image with ‘docker-exercise/ubuntu-wgetinstall ‘. This was created in the previous exercise.
As per our plan in this session I am using the below commands to run the ubuntu image as below:
sudo docker run -d ubuntu \
/bin/bash -c "while true; do date; sleep 5; done"; ========== Output ======> vskumar@ubuntu:~$ sudo docker run -d ubuntu \ > /bin/bash -c "while true; do date; sleep 5; done"; 0fe495fc93edee3aaadc7fc0fbf21997f0ca3cde4d7e563aa8c61352a43957dd vskumar@ubuntu:~$ $ =======================>
Now, to view the docker logs I want to run the docker logs subcommand on image id: ‘ 0fe495fc93edee3aaadc7fc0fbf21997f0ca3cde4d7e563aa8c61352a43957dd’
$ sudo docker logs 0fe495fc93edee3aaadc7fc0fbf21997f0ca3cde4d7e563aa8c61352a43957dd;
=====See the output of the Daemon process running with the ubuntu image ===============>
vskumar@ubuntu:~$ sudo docker logs 0fe495fc93edee3aaadc7fc0fbf21997f0ca3cde4d7e563aa8c61352a43957dd;
Sun Dec 3 05:11:57 UTC 2017
Sun Dec 3 05:12:02 UTC 2017
Sun Dec 3 05:12:07 UTC 2017
Sun Dec 3 05:12:12 UTC 2017
Sun Dec 3 05:12:17 UTC 2017
Sun Dec 3 05:12:22 UTC 2017
Sun Dec 3 05:12:27 UTC 2017
Sun Dec 3 05:12:32 UTC 2017
Sun Dec 3 05:12:37 UTC 2017
Sun Dec 3 05:12:42 UTC 2017
Sun Dec 3 05:12:48 UTC 2017
Sun Dec 3 05:12:53 UTC 2017
Sun Dec 3 05:12:58 UTC 2017
Sun Dec 3 05:13:03 UTC 2017
Sun Dec 3 05:13:08 UTC 2017
Sun Dec 3 05:13:13 UTC 2017
Sun Dec 3 05:13:18 UTC 2017
Sun Dec 3 05:13:23 UTC 2017
Sun Dec 3 05:13:28 UTC 2017
Sun Dec 3 05:13:33 UTC 2017
Sun Dec 3 05:13:38 UTC 2017
Sun Dec 3 05:13:43 UTC 2017
Sun Dec 3 05:13:48 UTC 2017
Sun Dec 3 05:13:53 UTC 2017
Sun Dec 3 05:13:58 UTC 2017
Sun Dec 3 05:14:03 UTC 2017
Sun Dec 3 05:14:08 UTC 2017
Sun Dec 3 05:14:13 UTC 2017
Sun Dec 3 05:14:18 UTC 2017
Sun Dec 3 05:14:23 UTC 2017
Sun Dec 3 05:14:28 UTC 2017
Sun Dec 3 05:14:33 UTC 2017
Sun Dec 3 05:14:38 UTC 2017
Sun Dec 3 05:14:43 UTC 2017
Sun Dec 3 05:14:48 UTC 2017
Sun Dec 3 05:14:53 UTC 2017
Sun Dec 3 05:14:58 UTC 2017
Sun Dec 3 05:15:03 UTC 2017
Sun Dec 3 05:15:08 UTC 2017
Sun Dec 3 05:15:13 UTC 2017
Sun Dec 3 05:15:18 UTC 2017
Sun Dec 3 05:15:23 UTC 2017
=================You can see the output for every few seconds listed =======>
It means the container is running as a daemon.
Now, let us use ps -eaf command to check the processed running in linux by using :
$ ps -eaf | grep ‘daemon’
========= See the output of daemon processes ==========>
vskumar@ubuntu:~$ ps -eaf | grep ‘daemon’
message+ 837 1 0 20:26 ? 00:00:05 /usr/bin/dbus-daemon –system –address=systemd: –nofork –nopidfile –systemd-activation
root 871 1 0 20:26 ? 00:00:03 /usr/sbin/NetworkManager –no-daemon
avahi 873 1 0 20:26 ? 00:00:00 avahi-daemon: running [ubuntu.local]
root 876 1 0 20:26 ? 00:00:01 /usr/lib/accountsservice/accounts-daemon
avahi 893 873 0 20:26 ? 00:00:00 avahi-daemon: chroot helper
rtkit 1370 1 0 20:28 ? 00:00:00 /usr/lib/rtkit/rtkit-daemon
vskumar 2426 1 0 20:55 ? 00:00:00 /usr/bin/gnome-keyring-daemon –daemonize –login
vskumar 2508 2428 0 20:55 ? 00:00:00 upstart-udev-bridge –daemon –user
vskumar 2515 2428 0 20:55 ? 00:00:04 dbus-daemon –fork –session –address=unix:abstract=/tmp/dbus-nPaV5rWlQc
vskumar 2570 2428 0 20:55 ? 00:00:03 /usr/lib/x86_64-linux-gnu/bamf/bamfdaemon
vskumar 2572 2428 0 20:55 ? 00:00:04 /usr/bin/ibus-daemon –daemonize –xim –address unix:tmpdir=/tmp/ibus
vskumar 2575 2428 0 20:55 ? 00:00:00 upstart-file-bridge –daemon –user
vskumar 2579 2428 0 20:55 ? 00:00:00 upstart-dbus-bridge –daemon –system –user –bus-name system
vskumar 2582 2428 0 20:55 ? 00:00:00 upstart-dbus-bridge –daemon –session –user –bus-name session
vskumar 2605 2428 0 20:55 ? 00:00:00 /usr/lib/ibus/ibus-x11 –kill-daemon
vskumar 2630 2428 0 20:56 ? 00:00:00 gpg-agent –homedir /home/vskumar/.gnupg –use-standard-socket –daemon
vskumar 2645 2428 0 20:56 ? 00:00:02 /usr/lib/unity-settings-daemon/unity-settings-daemon
vskumar 2664 2653 0 20:56 ? 00:00:00 /usr/bin/dbus-daemon –config-file=/etc/at-spi2/accessibility.conf –nofork –print-address 3
vskumar 2851 2654 0 20:56 ? 00:00:01 /usr/lib/unity-settings-daemon/unity-fallback-mount-helper
vskumar 2914 2428 0 20:57 ? 00:00:00 /bin/sh -c /usr/lib/x86_64-linux-gnu/zeitgeist/zeitgeist-maybe-vacuum; /usr/bin/zeitgeist-daemon
vskumar 2920 2914 0 20:57 ? 00:00:00 /usr/bin/zeitgeist-daemon
vskumar 3094 2428 0 21:00 ? 00:00:01 /usr/lib/x86_64-linux-gnu/unity-lens-files/unity-files-daemon
root 4148 1253 0 21:11 ? 00:00:00 docker-containerd-shim –namespace moby –workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/0fe495fc93edee3aaadc7fc0fbf21997f0ca3cde4d7e563aa8c61352a43957dd –address /var/run/docker/containerd/docker-containerd.sock –runtime-root /var/run/docker/runtime-runc
vskumar 4480 3206 0 21:19 pts/19 00:00:00 grep –color=auto daemon
======== You can see the list of processes running currently ========>
So we are successful! to run a container in a detached mode [not in an interactive mode!] using the command: ‘ sudo docker run -d ubuntu’
You can think in an application architecture having multiple servers or SOA running with different services.
You can simulate the same services using the docker containers, by setting up as images by configuring the required services and connect them to the architecture.
This way the advantages of containers can be utilized well. Where different companies are using and implementing their applications into containers architecture by saving lot of infrastructure cost. No hardware or physical servers are required. Lot of space also can be saved. The microservices architecture leads to the same way.
At this point, I would like to stop this session and in the next blog we will see other exercises.
In continuation of my previous blog [https://wordpress.com/post/vskumar.blog/1944] on this subject following questions and answers are continued:
1. What is a collaborative development approach in agile development model ?
Ans: In any agile project as per the Agile manifesto principles the team need to pull up the ideas through a prototype like; either phased prototype or iterative prototype or rapid prototype. With these pulled ideas, the team need to work together by sharing knowledge among themselves and which is considered as a collaborative development approach.
2. What is model storming during construction phase of an agile development model?
Ans: When the initial requirements are envisioned they all are being transmitted into different iterations. A single team or multiple teams need to execute the iteration during software code construction. The requirements also can be changed or newly added by the stakeholders as per the agile principles at any stage of Agile project phases. The team need to be brain stormed to execute the iterations correctly and completely as per the user’s desire. The iteration can be considered as a single agile model for construction phase and this model storming can happen within team for clear understanding of SPRINT by each developer. During the model storming; the requirements decomposition happens like; from user story to design specifications those can lead to SPRINT items, and from design to code specifications. Depends on the team planning; sometimes the outcome of model storming can also be a TDD [Test Driven Design]. [Please look into my youtube videos on Agile topic reusable code example]
3. What is Test Driven Design [TDD]?
Ans: Any requirement [story] need to be decomposed into design requirement. Each design requirement need to be converted into code through construction phase. When the code is visualized [before development] by the developer a test driven scenario need to be identified or visualized by the developer and it need to be documented into a test case with different test design steps. Once the developer feels this test case can be executed by using different code paths the developer can start the code writing, this concept is called Test Driven Design and using this TDD specification the development can be started. Hence the Agile developers need to make TDD 1st ready and plan for code writing, review and unit testing. Sometimes the TDD can be the outcome of the model storming also.
4. What is confirmatory testing?
Ans: In any software build there can be defects through different levels of testing. When the developer fixes one or more defects and deploy code in test environment, the test engineer need to retest it for confirming the software function with reference to the regression requirements or functionality and the fixes [if any]. For every fix confirmation test is mandatory.
5. What is evolving documentation?
Ans: As per the agile process when the code is constructed and tested the prepared documents need to be updated with reference to the tested and certified build. If any new requirement has to be incorporated into document, the documentation evolving is an ongoing activity for an iteration build till it goes to production.
6. What is internally deploying software?
Ans: Once the construction is over for an iteration requirement, software can be unit tested and integration tested. If it is passed, it can be move to other test environments. As per the deployment process when we are moving software into the different environments [after test certification or confirmation] the build is known as internally deployable software.
7. When can you finalize the documentation in agile model?
Ans: During the transition stage once the acceptance test is signed off users suggestions are considered to finalize the documentation.
8. What are tangible and intangible benefits for users?
Ans: In any business requirements there are direct benefits from business to incorporate software requirements into software system which is considered as tangible [direct] benefits. There are intangible [indirect benefits] also by incorporating different requirements into software with a business usage.
Example: If the system performance is increased by a technical design in the software architecture, users can access the data faster which is intangible benefits. Then the iteration can facilitate to perform the software with faster data access or the web pages appearance can be faster. Sometimes this kind of requirements can come into technical areas rather than coming through a user story in Agile and those can be intangible benefit. Even we might consider an upgrade to database or OS or memory, etc. then also the data access speed can be increased.
9. What is the feedback analysis? When it can be done?
Ans: As per the agile principles the stakeholder collaboration is an ongoing activity. At any time the stakeholder can give informal or formal feedback for any software items or in any approach followed by agile teams. In agile model many times informal feedback can happen during the discussion. At the same time the scheduled reviews also can happen. During the review the feedback can be given by the reviewers. Even a test result can come into a feedback category. All these feedback items need to be analyzed for delivering a working software by the teams as per the principles. Sometimes the feedback analysis outcome can come into process improvements areas for the next iteration and these should be considered for Retrospective items. Hence the feedback analysis is a mandated activity at every task completion stage in Agile project.
10. What is demo in agile model?
Ans: With reference to the rapid prototype approach agile teams are supposed to demonstrate skeleton design for a new module. it is a plan to demonstrate skeleton system to the stakeholder and to get the feedback for processing further SPRINT or Iteration items. This demo is organized depends on the software or initial plan for a given iteration.
Keep watching this site for further updates.
Contact for any guidance/coaching.