在Docker中的不同内核中编译代码会受到什么影响？ [英] what will be impacted for compiling code in different kernel in docker?
问题描述
我可以信赖在Ubuntu 14.04主机中的用于c / c ++源代码的redhat6.4的docker容器中的构建？或者我需要考虑的任何限制？
我们正试图使用docker来提供不同的操作系统平台来编译源代码，因为docker中的技术是共享主机的内核，请参阅相关问题 Docker主机操作系统和容器基础映像OS之间的关系是什么？
- 我的主机操作系统是ubuntu 14.04（easy安装docker），内核是
3.13.0-24-generic - 我的应用程序平台是redhat 6.4（内核是
2.6.32-358.el6.x86_64）
当我为RHEL创建容器对于Ubuntu，内核更新为 3.13.0-24-generic 。
我的应用程序是c / c ++&基于java的。
我不认为对于编译的 .jar 文件来说，java将是任何问题，因为它是基于jvm。
对于c / c ++代码，大多数我明白这取决于 libc 共享库，不依赖于内核，所以可以将这个编译的代码用到真正的redhat环境中。
此设置仅用于开发，不用于生产，生成的二进制文件应该是使用RHEL或VM安装真正的独立机器。
所以我需要考虑的任何事情？
更新以添加一些示例
我下载游戏生活代码 https://github.com/rvsjoen/game-of-life ，并在两个系统中编译，寻找这种情况，因为md5是一样的，结果是一样的，它是可信的。
这是VM中的redhat 6.4系统
[root @ redhat game-of-life-master] ＃cat / etc / redhat-release
红帽企业Linux服务器版本6.4（圣地亚哥）
[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
这是在docker容器中的redhat
bash-4.1＃cat / etc / redhat-release
红帽企业Linux服务器版本6.4（圣地亚哥）
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
c / c ++代码是否有异常？
在正常情况下，本机编译代码（C，C ++ ...）没有例外。
As你写的，程序与 libc 交互，而不是内核，除非非常特殊的情况。
这个<$ c您的Ubuntu主机和Redhat容器之间不共享$ c> libc 库。您的容器有自己的 libc ，它将系统调用抽象到内核。
关于内核本身，如果Linux内核的内容往往是移动的，那么总是不断发展的代码片段，公开的内容（ABI，用户空间应用程序和 libc 可访问）保持稳定和兼容版本。在罕见的情况下，这种兼容性已经被破坏了，大多数时候，不是故意的。 （请参阅本文）。
所以，是的，使用RHEL dev是完全安全的。 Ubuntu主机上的环境，并且信任从此容器生成的构建。
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 ?
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 special situations.
This libclibrary is not shared between your Ubuntu host and your Redhat container. Your container has its own libcthat abstracts system calls to the kernel.
About the kernel itself, note the 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.
这篇关于在Docker中的不同内核中编译代码会受到什么影响？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
