Могу ли я доверять сборкам в Docker-контейнере для redhat6.4 в хосте Ubuntu 14.04 для исходных кодов c / c ++? или какое-то ограничение мне нужно учитывать?
Мы пытаемся использовать docker для обслуживания различных платформ ОС для компиляции исходных кодов, так как технология в docker — это совместное использование ядра host os, см. Связанный вопрос Какова связь между операционной системой хоста докера и операционной системой базового образа контейнера?
3.13.0-24-generic
2.6.32-358.el6.x86_64
)Когда я создал контейнер для RHEL для Ubuntu, ядро обновилось до 3.13.0-24-generic
также.
Мое приложение с / с ++ & на основе Java.
Я не думаю, что Java будет проблемой для скомпилированного .jar
файлы, так как он основан на JVM.
И для кодов c / c ++, в основном я понимаю, это зависит от libc
вид разделяемой библиотеки, не зависит от ядра, поэтому возможно использовать этот скомпилированный код в реальной среде redhat.
Эта настройка используется только для разработки, а не для производства, предполагается, что сгенерированные двоичные файлы должны быть установлены на реальных автономных машинах с RHEL или VM.
Итак, какие вещи мне нужно рассмотреть?
Вероятно, это более lxc связанный вопрос.
Обновлено, чтобы добавить образец
Я скачиваю игру из кодов жизни https://github.com/rvsjoen/game-of-life, и скомпилированный в обеих системах, ищет этот случай, так как md5 одинаков, результат одинаков и заслуживает доверия.
Это система Redhat 6.4 в ВМ
[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
А это редхат в докере
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
Есть ли исключения для кодов c / c ++?
В обычных ситуациях нет исключений для скомпилированных кодов (C, C ++ …).
Как вы писали, программы взаимодействуют с libc
не ядро, кроме очень специфических ситуаций.
это libc
библиотека не является общей для вашего хоста Ubuntu и вашего контейнера Redhat. Ваш контейнер имеет свой собственный libc
это обобщает системные вызовы ядра.
Что касается самого ядра, обратите внимание, что даже если внутренние компоненты ядра Linux, как правило, движутся, всегда развивая фрагменты кода, то, что открыто для общественности (ABI, доступно для приложений пользовательского пространства и libc
) поддерживается стабильно и совместимо между выпусками. В редких случаях эта совместимость нарушалась, чаще всего не преднамеренно. (увидеть Эта статья).
Так что да, использование RHEL dev совершенно безопасно. окружение на хосте Ubuntu, и доверять сборкам, сгенерированным из этого контейнера.