It is necessary to install various dependent libraries in the C language development environment. Therefore, it is difficult to unify the environment of each developer. Until now, in order to unify the environment,
--All developers develop using the same machine development environment --Create and distribute the development environment construction procedure manual --Distribute the VM image of the development environment
I had to do something like that. But now there is a convenient thing called a container. The author has also created a development & test environment on AWS EC2 and provided it to developers. Currently, we provide Docker files and Docker images. Here, we will create a Dockerfile and an image and explain how to use them.
The environment in which the Docker container operates, such as Docker for Mac / Windows, must be installed. Also, a little knowledge of Docker and Linux is required. In addition, this article describes the work contents on mac. When working on Windows, please read the path etc. as appropriate.
In this article, you will be able to do the following on CentOS in Docker containers:
The docker file is a blueprint for creating a container image. Before using the container, I had to manually install the OS and libraries. If you write the procedure in a Dockerfile instead of writing it down, you can easily reproduce it. This is exactly the first step in ** Infrastructure as Code (IaC) **.
First, decide where to make the image. Create / place a Dockerfile there.
> cd ~/docker/
Dockerfile
The completed version is from here (Dockerfile) I will describe various things in the Dockerfile.
Please choose your favorite OS. Here, CentOS 7 is selected as the development environment.
From centos:7
Specify the directory where you want to install.
WORKDIR /root
Install your favorite packages with yum. If you develop in C, yum group install is convenient. The image will be larger, but it should be fine in a development environment.
RUN yum -y update && \
yum -y groupinstall "Development Tools"
Others are free! Here (Dockerfile) describes the ones that are likely to be used normally.
Import the file from the file system of the host PC into the image.
COPY .bashrc /root/
This time I want to keep the environment variables set when the shell is executed, so I added .bashrc to the image. I will. If you have the files you need COPY [File on host PC] [Location in Docker image] Please add with.
Go to the directory containing the Docker files (here ~ / docker /) and build.
> cd ~/docker/
> docker build -t c_dev_env .
It will take some time.
> docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
c_dev_env latest aa8cc7f4372f About an hour ago 1.45GB
This completes the Docker image "c_dev_env".
Reference In order to register (push) to DockerHub, it is necessary to add [organization] to the tag (-t option).
docker build -t [organization]/c_dev_env .
This is the most important part of this article. The gdb command uses system calls and cannot be executed without the appropriate options.
docker run -it --name "my_dev_env" --cap-add=SYS_PTRACE --security-opt="seccomp=unconfined" c_dev_env /bin/bash
** Explanation of options and parameters **
Options / parameters | Description |
---|---|
-i | (--interactive)use stdin |
-t | Enable tty |
--name | Give a name. here"my_dev_env" |
--cap-add=SYS_PTRACE | Linux Capability ptrace()Allow system calls.(Reference) Man page of Capabilities |
--security-opt="seccomp=unconfined" | Avoid system calls because system calls are restricted even with the seccomp mechanism.(reference)Control docker system calls using seccomp profile |
Parameter 1 | Image name. Here c_dev_Specify env |
Parameter 2 | Execution command. here/bin/Specify bash |
-v [Host PC directory]: It is convenient to mount it in [Container directory]. You can develop with a familiar editor on the host PC.
> docker run -it --name "my_dev_env" --cap-add=SYS_PTRACE --security-opt="seccomp=unconfined" c_dev /bin/bash
bash-4.2# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
bash-4.2#
The execution environment is now complete.
Now let's create a simple program and run it. In the Docker image under / root / sample
bash-4.2# cd /root
bash-4.2# mkdir sample
bash-4.2# cd sample
bash-4.2# vi hello.c
Program creation hello.c
hello.c
#include <stdio.h>
int main(void)
{
int sum = 0;
sum++;
printf("Hello, World!\n");
printf("sum = %d\n", sum );
return 0;
}
And compile
gcc -g -o hello hello.c
-g: Don't forget the debug options!
bash-4.2# gcc -g -o hello hello.c
bash-4.2# ls -la
total 24
drwxr-xr-x 2 root root 4096 Jun 23 14:24 .
dr-xr-x--- 1 root root 4096 Jun 23 14:23 ..
-rwxr-xr-x 1 root root 9528 Jun 23 14:24 hello
-rw-r--r-- 1 root root 136 Jun 23 14:24 hello.c
bash-4.2# ./hello
Hello, World!
sum = 1
I can do it properly.
Now let's debug with gdb
bash-4.2# gdb hello
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
~ Omitted ~
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/sample/hello...done.
(gdb)
The prompt came out without any error. Next, set a breakpoint and execute a step
(gdb) l <---List display
1 #include <stdio.h>
2
3 int main(void)
4 {
5 int sum = 0;
6 sum++;
7 printf("Hello, World!\n");
8 printf("sum = %d\n", sum );
9 return 0;
10 }
(gdb) b 6 <---Breakpoint setting on line 6
Breakpoint 1 at 0x40056c: file hello.c, line 6.
(gdb) r <---Run
Starting program: /root/sample/hello
Breakpoint 1, main () at hello.c:6
6 sum++; <---Stopped at a breakpoint!
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.5.x86_64
(gdb) n <---Step execution
7 printf("Hello, World!\n");
(gdb) p sum <---Variable content display
$2 = 1
Breakpoint setting and step execution are done without any problem.
Finally, Ctrl + p, Ctrl + q to get out of Linux in the Docker container.
When connecting again, docker attach [tag name]
> docker attach my_dev_env
bash-4.2#
** Infrastructure as Code (IaC) ** is an essential technical element for building large-scale system environments, especially in public clouds and container orchestration environments. However, I was a little impressed that I could experience it even in such a familiar environment. (It is natural)
--Write the installation procedure in Dockerfile --Write the environment construction procedure manual in the playbook
This is also an important element of ** Infrastructure as Code (IaC) **, and this alone Toyle ( SRE Site Reliability Engineering Chapter 5) I feel that we can definitely reduce it. However, be careful about personalization by Dockerfile craftsmen and Playbook craftsmen.