Update to reflect the current situation in the year 2025 #16
Conversation
| @@ -8,12 +8,13 @@ All modifications to the repositories and images must be submitted via a Pull Re | |||
|
|
|||
| ## Dockerfile Guidelines | |||
|
|
|||
| The images under SCLOrg generally follow [Container Best Practices](http://docs.projectatomic.io/container-best-practices/). Please read through them before submitting a PR. | |||
There was a problem hiding this comment.
I would not recommend switching to Docker's best practices unless we are really ok with following them. Needs more research.
Maybe we could instead incorporate the no-longer-available atomic best practices into this doc directly?
There was a problem hiding this comment.
@phracek where do I find gudelines we want to stick to ?
There was a problem hiding this comment.
The container best practices that I found are here: https://docs.docker.com/build/building/best-practices/
There was a problem hiding this comment.
The Project Atomic no longer exist and it's successor, the CoreOS, does things differently.
This might be a good time to reflect on what guidelines and goals we want to follow.
Take over Project Atomics docs we want to uphold ourselves and find new sources for the rest.
e.g. line 13.
| @@ -55,11 +56,12 @@ Also, the source code changes between particular versions should be kept as smal | |||
|
|
|||
| ### EOL versions | |||
|
|
|||
| -- FIX TO REFLECT REALITY -- | |||
There was a problem hiding this comment.
It is on the maintainer's discretion wheter or not to clean up older sources. So we can just document it like that.
There was a problem hiding this comment.
@phracek I got a feeling that rather than it being optional, you purge the old versions periodically (once or twice a year?) after they reach EOL.
There was a problem hiding this comment.
As is mentioned below the source files will be retained in the repository after couple of months or year, we discussed whether the old sources will be removed. But there should be some newer version so we have Git history. I would leave it as it is.
| @@ -55,11 +56,12 @@ Also, the source code changes between particular versions should be kept as smal | |||
|
|
|||
| ### EOL versions | |||
|
|
|||
| -- FIX TO REFLECT REALITY -- | |||
There was a problem hiding this comment.
As is mentioned below the source files will be retained in the repository after couple of months or year, we discussed whether the old sources will be removed. But there should be some newer version so we have Git history. I would leave it as it is.
| @@ -8,12 +8,13 @@ All modifications to the repositories and images must be submitted via a Pull Re | |||
|
|
|||
| ## Dockerfile Guidelines | |||
|
|
|||
| The images under SCLOrg generally follow [Container Best Practices](http://docs.projectatomic.io/container-best-practices/). Please read through them before submitting a PR. | |||
There was a problem hiding this comment.
The container best practices that I found are here: https://docs.docker.com/build/building/best-practices/
|
|
||
| ## Packages installing in Dockerfile | ||
|
|
||
| When installing packages in the Dockerfile, it is important to ensure that all packages come from official repositories and are installed using conventional methods such as YUM or DNF. Only scripts that are available in these repositories should be added to the images on top of the RPM data. | ||
|
|
||
| For Fedora images, we aim to use the modules from [Modularity effort](https://docs.pagure.org/modularity/). | ||
|
|
||
| -- UPDATE INFO -- | ||
| For CentOS, we take packages from [SCLo SIG](http://wiki.centos.org/SpecialInterestGroup/SCLo). As a result, the images use RPM packages from the [Software Collections](http://softwarecollections.org). |
| For CentOS, we take packages from [SCLo SIG](http://wiki.centos.org/SpecialInterestGroup/SCLo). As a result, the images use RPM packages from the [Software Collections](http://softwarecollections.org). | ||
|
|
||
| -- UPDATE INFO (only Red Hat?) -- | ||
| For RHEL, we install packages from RHEL 7 base or Red Hat [Software Collections](https://access.redhat.com/documentation/en/red-hat-software-collections/). |
| - [spec2scl](https://github.com/sclorg/spec2scl): A Python-based tool that facilitates the migration of RPM spec files into SCL-enabled variants by adding macros, scriptlets, and more. | ||
| - [SCLOrg](https://github.com/sclorg/softwarecollections): Source code for the [SCLOrg](http://softwarecollections.org/) website, a Django application that serves as a directory for available Software Collections Organization. | ||
| - [centpkg for SCLo](https://github.com/sclorg/centpkg-sclo): A compact wrapper that assists [SCLo SIG](http://wiki.centos.org/SpecialInterestGroup/SCLo) maintainers in building SCL packages in [CBS](http://cbs.centos.org/). | ||
| - [centos-release package](https://github.com/sclorg/centos-release-scl): A minimal RPM package with a YUM repository, offering upstream Software Collections built in [CBS](http://cbs.centos.org/) by the community (excluding those in RHSCL). | ||
| -- FIX URL (ci.centos.org) -- | ||
| - [SCLo CI Tests](https://github.com/sclorg/sclo-ci-tests): Tests executed in [CentOS CI](http://ci.centos.org) to verify the successful (re)building of RPM packages in [CBS](http://cbs.centos.org/). |
There was a problem hiding this comment.
@phracek
Is there any successor of the ci.centos.org ?
There was a problem hiding this comment.
This can be removed. We do not use it at all.
| @@ -25,6 +24,7 @@ In light of recent developments, we have introduced a series of RPMs web develop | |||
| Kubernetes (commonly referred to as k8s) has emerged as the de-facto standard for orchestrating containers, enabling the large-scale management and configuration of containers as cattle rather than pets. OpenShift is a Platform-as-a-Service (PaaS) built on top of Kubernetes, providing comprehensive application lifecycle management. This includes the ability to quickly build and deploy Docker-formatted containers while managing them on a robust, scalable platform. To learn more about these two technologies, explore the following resources: | |||
|
|
|||
| - https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/#kubernetes-is | |||
| -- FIX URL FOR RHEL 8 or later -- | |||
| - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/getting_started_with_kubernetes/ | |||
There was a problem hiding this comment.
@phracek
I can find this for later RHELs. What's the correct current URL?
No description provided.