what will be impacted for compiling code in differ

问题:

Can I trust the builds in docker container for redhat6.4 in Ubuntu 14.04 host for c/c++ source codes ? or any limitation I need to consider ?

We are trying to use docker to serve different OS platform to compile the source codes, since technology in docker is share the host os's kernel, see related question What is the relationship between the docker host OS and the container base image OS?

• My host OS is ubuntu 14.04 (easy to install docker), kernel is 3.13.0-24-generic
• My application platform is redhat 6.4 (kernel is 2.6.32-358.el6.x86_64)

When I created the container for RHEL for Ubuntu, the kernel is updated to 3.13.0-24-generic as well.

My application is c/c++ & java based.

I don't think java will be any problem for the compiled .jar files since it is based on jvm.

And for c/c++ codes, mostly I understand it depends on libc kind of shared library, not depends on kernel, so is it possible to use this compiled codes into real redhat environment.

This setup is used for development only, not for production, the generated binary files are supposed to be installed real standalone machines with RHEL or VM.

So any things I need to consider ?

Probably it is more lxc related question.

Updated to add some sample

I download the gameoflife codes https://github.com/rvsjoen/game-of-life, and compiled in both system, looks for this case since md5 is the same, the result is the same and it is trustable.

This is redhat 6.4 system in VM

[root@redhat game-of-life-master]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
[root@redhat game-of-life-master]# uname -a
Linux redhat 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64x86_64 GNU/Linux
[root@redhat]# ldd gol
    linux-vdso.so.1 =>  (0x00007fffaeaa8000)
    libncurses.so.5 => /lib64/libncurses.so.5 (0x00000033fa000000)
    libc.so.6 => /lib64/libc.so.6 (0x00000033f9c00000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00000033fb800000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000033f9800000)
    /lib64/ld-linux-x86-64.so.2 (0x00000033f9400000)
[root@redhat]# md5sum gol
4f3245d3d61b1c73e48537dd612d37c3  gol

And this is redhat in docker container

bash-4.1# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
bash-4.1# uname -a
Linux f51c7b4e80aa 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
bash-4.1# ldd gol
    linux-vdso.so.1 =>  (0x00007fff5e3c2000)
    libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f2e84863000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f2e844d0000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f2e842ae000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f2e840aa000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2e84a8e000)
bash-4.1# md5sum gol
4f3245d3d61b1c73e48537dd612d37c3  gol

Are there any exception for c/c++ codes ?

回答1:

There is, in normal situations, no exception for natively compiled codes (C, C++...).

As you wrote, programs interact with the libc, not the kernel, except very specific situations.

This libclibrary is not shared between your Ubuntu host and your Redhat container. Your container has its own libc that abstracts system calls to the kernel.

About the kernel itself, note that even if the Linux kernel internals tend to be moving, always evolving pieces of code, what is publicly exposed (the ABI, accessible to userspace applications and libc) is kept stable and compatible between releases. In rare occasions this compatibility has been broken, most of the time, not intentionally. (see this article).

So, yes, it is perfectly safe to have use a RHEL dev. environment on an Ubuntu host, and to trust the builds generated from this container.

回答2:

There are no problems while the App does not directly use the last feature of a certain linux kernel.

Docker works at the lowest level intercepting only all "system calls".

In Linux 64 (x64) system calls are made with the intel / amd processor assembler instruction: SYSCALL

This SYSCALL is the one that is "intercepted" by the KERNEL of LINUX and "virtualized" with docker by internally changing the operation of the invocation.

For example, the system call "open", to open a disk file, changes the path to the file by another one where the "root" of the running docker image is located.

I do not know exactly what level of the kernel that change is made, if it is when entering "open", or if it is more internally.

For this reason, the same binary executable that works in a linux without docker, works inside a docker image, without modifying the executable at any time.

All the "virtualization" is done inside the KERNEL, which is entered for example with SYSCALL.

But beware of applications that use the latest "feature" of a kernel. Because it may not run ok, if the kernel below it does not have that "feature".

Beware of security patches at the kernel level, the kernel below may not have such a patch. In turn it is easier to install these security patches and maintain secure systems, since they are not "part" of the APPs. This is another advantage with respect to VM images.