Hi, i just joined in this forum and am excited to be here, apologize if I make a mistake in this very first thread.
I’m building the container image from Leap Base Container Image ( registry.opensuse.org/opensuse/leap) for my Python application, and it worked great for my development environment, i put that container image in Docker Hub. But openSUSE recommended us on Twitter to use SUSE BCI images instead. My concern is redistribute the container images built based SUSE BCI image to my clients, will there be any problems with SUSE subscriptions later? especially when the host isn’t SLE Server or SLE Micro.
I’d like to know from anybody who experienced building BCI form both openSUSE or SUSE to give me some advice. I’ve delivered my applications traditionally to openSUSE Leap servers for years, it’s just fine to me using Leap BCI for delivering my container image.
Many thanks,
Hanan D.
Welcome!
Subscriptions shouldn’t be an issue using the BCI images for SUSE Linux Enterprise, because you should never update the software in those containers using the SUSE software management; you should instead use those images as a base upon which you overlay your software in the Dockerfile (or docker-compose file, or whatever you’re using for building your container images). But to understand more specifically what the limitations or potential pitfalls are for using the SLE images, you should ask in the SUSE forums rather than here. 
Alternatively, the tweet does suggest using the Tumbleweed images as well. Tumbleweed is upstream from SUSE Linux Enterprise, and is a good choice for what you’re looking to do as well.
Leap is going to be around for a while - there’s a roadmap for a 15.6 release (which just entered the very early alpha stage last week). There’s been some talk about what Leap looks like when the SUSE ALP project starts seeing its “final” release schedule (it’s currently in pre-release status).
Hi, thanks for answering my concern.
I’ve learned SUSE BCI at this page, but i’m afraid there’s missing part that i don’t know or dont understand about. Perhaps i should go to SUSE forums as you recommended.
Yes, i’m aware it did mention the Tumbleweed image on the tweet, I can use it for development purposes (and I’m running Aeon for my development machine which is Tambleweed with atomic transaction) but when I decided to deliver to my clients, it needs production ready images like Leap or SLE. Lucky me when they’d choose SLE in their production servers, but if they won’t, i must go to the alternatives.
I’d love to follow this roadmap and whatever Leap will become of. Leap did the great job.
Many thanks,
Hanan D.
There’s nothing particularly “not-production-ready” about Tumbleweed, particularly as a container base. You decide if the image works with your application on it in the TW container - and you control what updates are built ino that container, as container design isn’t intended to be used as a virtualization replacement where your clients would update the “OS” in the container the way they might in a virtual environment or on bare metal.
When you update your container, build with the latest base and test, then distribute the container (upload to Docker hub, or whatever container repository you use for distribution).
Your clients then have a container image that they use. They don’t mess with what’s inside the container, because what you built with is what you decide to support.
Similarly, whether or not they use SLE on their production servers makes no difference to the packages installed in the container; I’ve got distropod installations of different distributions running on Tumbleweed, which lets me run packages built for Ubuntu (for example) without having to run a virtual environment. Doesn’t matter that I’m not running Ubuntu on my system installation.
That’s the beauty of containers. They’re not intended to be used as a “virtualization” replacement (though you can do that). They ideally contain as little as possible in order to run the application you want to run in them. I’ve got multiple Docker containers running Alpine’s HTTPD (apache) image, each with their own configuration and listening on a different port behind a reverse proxy. If I need another instance for some reason, I just spin up another httpd:alpine container - and it only contains the minimum set of Alpine-based libraries needed to run Apache - nothing else.
In terms of the Leap roadmap, you’ll find that at openSUSE:Roadmap - openSUSE Wiki.
Hi, thanks for your explanation.
I have a case, for example I put the maintenance window in the production server for my container image, let’s say I give my client support every month or two it’ll pull the updated image that I built privately. The first time I built the image support Python 3.11, because Tumbleweed always rolling to the latest software, maybe the next 6 months Python 3.11 isnt supported anymore due to EOL.
Of course I don’t have to use Leap/SLE or Tw as base image, but at least with SLE/Leap image, it’ll guarantee us to support the latest version of production software, in this case Python 3.11 just like Leap/SLE still support Python 3.6 (which is EOL) for production server.
– Hanan D.
I see what you’re saying; looking through the default repos for TW right now, I see python 3.8, 3.9, 3.10, 3.11, and 3.12.
Compatibility within the Python 3 family also seems to generally be pretty good, though the Python work I do doesn’t tend to use a lot of different modules, either, so YMMV.
1 Like