Would Container technology help to satisfy multiple dependencies for a RHEL OS?
Linux - EnterpriseThis forum is for all items relating to using Linux in the Enterprise.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Would Container technology help to satisfy multiple dependencies for a RHEL OS?
I'm helping a developer setup a RHEL 6.4 system for an application that he is building.
Unfortunately in order to get this app to work correctly, it needs a number of packages that are newer then what comes with the install ISO.
My original plan was to create a local repo and install those packages, however that won't work.
I'm not sure what the best solution would be for this? Would setting up a Container with a RHEL OS that has the correct packages, which would get build in production, however we want to do all of this testing in development, in order to get this back in production.
Would this be the correct use of a Container in this situation?
I'm helping a developer setup a RHEL 6.4 system for an application that he is building.
Unfortunately in order to get this app to work correctly, it needs a number of packages that are newer then what comes with the install ISO.
My original plan was to create a local repo and install those packages, however that won't work.
I'm not sure what the best solution would be for this? Would setting up a Container with a RHEL OS that has the correct packages, which would get build in production, however we want to do all of this testing in development, in order to get this back in production.
Would this be the correct use of a Container in this situation?
Hopefully what I'm asking makes sense.
I have used OpenVZ containers (host at RHEL-6 with guest container CentOS-7) for this kind of development. An LXC container should work just as well and does not require changing to OpenVZ (as LXC support is in the kernel upstream). If you mean a KVM container, while heavier and less efficient that should serve just as well. Even VirtualBox or VMWARE (although quite slow ) would work for this.
You have, in fact, MANY solutions that do not require messing with your RHEL-6 supported packages and putting your server into an unsupported state.
I would create a CentOS-7 development container to compile your packages, and test there first. Static compile might be advisable if the package must work on multiple versions/releases. (Note the advantages and disadvantages, and perhpas leave that to your developers judgment.)
Then migrate it to the test server and hammer it there before migrating it to production.
I'm helping a developer setup a RHEL 6.4 system for an application that he is building.
Unfortunately in order to get this app to work correctly, it needs a number of packages that are newer then what comes with the install ISO.
My original plan was to create a local repo and install those packages, however that won't work.
I'm not sure what the best solution would be for this? Would setting up a Container with a RHEL OS that has the correct packages, which would get build in production, however we want to do all of this testing in development, in order to get this back in production.
Would this be the correct use of a Container in this situation?
You've been given good advice here by wpeckham, and I concur totally with it.
RHEL 6.4 is old..the latest is 7.x, so if this is, as you say, a new RHEL system for developing an application, why on earth would you start with an old OS with old packages? And unless you're paying for RHEL, you are in for problems too. You won't get any updates/patches/bug fixes/security fixes unless you do purchase a subscription. And for development...CentOS is totally free, and IDENTICAL to RHEL, so there's no benefit to using RHEL without paying.
You could 'container' this app, sure...but then you're only going to be asking any potential end-user to install the container apps/libraries to get things to work, as opposed to just saying "here's a list of supported OS versions". Installing your package after that with any package manager (zypper, yum, apt-get), will then also shove on any missing packages from the native repositories.
Just my $0.02 worth...better to build it right to start with, than to try to shoehorn it in with 'workarounds'.
The app currently works with RHEL 6.4. However we are testing it along with other Python 2.7 packages/libraries so that it will work a newer version of RHEL6. We have to work with the vendor on this. However I'm trying to speed up the deployment of this along with learning about Containers and what my options are for this.
RHEL 6.4 is supported till 2020 and we have a current subscription with Red hat.
Quote:
Originally Posted by TB0ne
RHEL 6.4 is old..the latest is 7.x, so if this is, as you say, a new RHEL system for developing an application, why on earth would you start with an old OS with old packages? And unless you're paying for RHEL, you are in for problems too. You won't get any updates/patches/bug fixes/security fixes unless you do purchase a subscription. And for development...CentOS is totally free, and IDENTICAL to RHEL, so there's no benefit to using RHEL without paying.
You've been given good advice here by wpeckham, and I concur totally with it.
Thank you, I do appreciate when someone knowledgeable supports my advice.
Quote:
You could 'container' this app, sure...but then you're only going to be asking any potential end-user to install the container apps/libraries to get things to work, as opposed to just saying "here's a list of supported OS versions". Installing your package after that with any package manager (zypper, yum, apt-get), will then also shove on any missing packages from the native repositories.
I was not talking about developing his app as a container, but compiling it for RHEL7/CentOS7 IN a container. Not an app container, but a full distro container. This can be easily done using LXC and its tools, or OpenVZ and its tools, and is easier and lighter than using a full virtual using XEN, VMWARE, KVM, or Virtualbox and results in executables that will run on any RHEL7 compatible system: physical or virtual.
I apologize for not making that clear in the earlier post.
Thank you, I do appreciate when someone knowledgeable supports my advice.
I was not talking about developing his app as a container, but compiling it for RHEL7/CentOS7 IN a container. Not an app container, but a full distro container. This can be easily done using LXC and its tools, or OpenVZ and its tools, and is easier and lighter than using a full virtual using XEN, VMWARE, KVM, or Virtualbox and results in executables that will run on any RHEL7 compatible system: physical or virtual.
I apologize for not making that clear in the earlier post.
No worries, you were clear, but the OP originally mentioned a container at the start. Wasn't sure which kind (VM or something like Docker) they meant.
The app currently works with RHEL 6.4. However we are testing it along with other Python 2.7 packages/libraries so that it will work a newer version of RHEL6. We have to work with the vendor on this. However I'm trying to speed up the deployment of this along with learning about Containers and what my options are for this.
RHEL 6.4 is supported till 2020 and we have a current subscription with Red hat.
RHEL 6.4 is not supported til 2020. The EUS (Extended Update Support) for RHEL 6.4 ended in March, 2015.
A standard subscription entitles you to updates for the current update level. It doesn't allow you to stay on a specific update unless you purchase an EUS as an add-on. A premium subscription includes EUS, but it doesn't extend the support time frame for an EUS.
So, unless you have a special contract with Red Hat for support well beyond the EUS date, you don't have a support for that version.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.