Hi all,
Do you provide an official docker image for 389 ? I plan to deploy MMR on Kubernetes . Any advice/link ?
On 10 Jun 2019, at 23:42, Olivier JUDITH gnulux@gmail.com wrote:
Hi all,
Do you provide an official docker image for 389 ? I plan to deploy MMR on Kubernetes . Any advice/link ?
I have been getting us "closer" to docker support for a while, and I think it's probably flowed enough into the pipe-lines to make an official image. I think that this is probably a conversation for 389-devel to go about this setup and testing process as part of a release, and Mark probably would have advice here. To put this in context, I do all development and testing of 389 today in docker!!!
Today I don't think that this image will work in K8s, because K8s is very opinionated about it's container configuration and setup. It has always been a goal to add this support, but initially I have targetted suse transactional server / fedora atomic. But we have a pretty solid foundation to start from.
Today we don't have much on the wiki about this, but I'm very happy to help out with how to build this if you need a custom image, and certainly if you have K8s experience, helping contribute automation for that into the project would be wonderful.
The following dockerfile is probably the "most complete" example we have, and is very likely what we would use for an official image for upstream due to the layering ability of obs for network:ldap to apply to stable suse.
https://build.opensuse.org/package/view_file/home:firstyear/389-ds-container...
Just change the FROM line to "opensuse/leap:15" - the current from line is an obs trick to make that image work.
It's great you're interested in this, so we'd love to have you help and advise us more on this!
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
On 11 Jun 2019, at 09:37, William Brown wbrown@suse.de wrote:
On 10 Jun 2019, at 23:42, Olivier JUDITH gnulux@gmail.com wrote:
Hi all,
Do you provide an official docker image for 389 ? I plan to deploy MMR on Kubernetes . Any advice/link ?
I have been getting us "closer" to docker support for a while, and I think it's probably flowed enough into the pipe-lines to make an official image. I think that this is probably a conversation for 389-devel to go about this setup and testing process as part of a release, and Mark probably would have advice here. To put this in context, I do all development and testing of 389 today in docker!!!
Today I don't think that this image will work in K8s, because K8s is very opinionated about it's container configuration and setup. It has always been a goal to add this support, but initially I have targetted suse transactional server / fedora atomic. But we have a pretty solid foundation to start from.
Today we don't have much on the wiki about this, but I'm very happy to help out with how to build this if you need a custom image, and certainly if you have K8s experience, helping contribute automation for that into the project would be wonderful.
The following dockerfile is probably the "most complete" example we have, and is very likely what we would use for an official image for upstream due to the layering ability of obs for network:ldap to apply to stable suse.
https://build.opensuse.org/package/view_file/home:firstyear/389-ds-container...
Just change the FROM line to "opensuse/leap:15" - the current from line is an obs trick to make that image work.
It's great you're interested in this, so we'd love to have you help and advise us more on this!
As an FYI I have the Open Build Service pipeline working now, so you can use the package here
docker pull registry.opensuse.org/home/firstyear/containers/389-ds-container:latest
I have already noticed some issues with it, so I'll be working to have these resolved ASAP. As always, feedback and improvements to our container are most welcome!
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
Hi,
Thank for the link , i tried to run your image but the container fails after few seconds . Seems that you forgot to create /var/run/dirsrv folder in Dockerfile .
the server crashes with : DEBUG: DEBUG: starting with ['/usr/sbin/ns-slapd', '-D', '/etc/dirsrv/slapd-localhost', '-i', '/var/run/dirsrv/slapd-localhost.pid'] CRITICAL: Error: Failed to start DS, removing incomplete installation... Failed to connect to bus: No such file or directory Failed to connect to bus: No such file or directory Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 654, in create_from_args self._install_ds(general, slapd, backends) File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 862, in _install_ds ds_instance.start(timeout=60) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1170, in start raise ValueError('Failed to start DS') ValueError: Failed to start DS
It works fine now, I start to write my k8s configuration . If you can just remind me where i can find documentation on lib389 used in your dscontainer python script ?
Keep you informed
On 12 Jun 2019, at 01:40, Olivier JUDITH gnulux@gmail.com wrote:
Hi,
Thank for the link , i tried to run your image but the container fails after few seconds . Seems that you forgot to create /var/run/dirsrv folder in Dockerfile .
There are some other errors in it too which I have found :)
the server crashes with : DEBUG: DEBUG: starting with ['/usr/sbin/ns-slapd', '-D', '/etc/dirsrv/slapd-localhost', '-i', '/var/run/dirsrv/slapd-localhost.pid'] CRITICAL: Error: Failed to start DS, removing incomplete installation... Failed to connect to bus: No such file or directory Failed to connect to bus: No such file or directory Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 654, in create_from_args self._install_ds(general, slapd, backends) File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 862, in _install_ds ds_instance.start(timeout=60) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1170, in start raise ValueError('Failed to start DS') ValueError: Failed to start DS
It works fine now, I start to write my k8s configuration .
Fantastic - can you post to me what you are doing with k8s so I can review?
If you can just remind me where i can find documentation on lib389 used in your dscontainer python script ?
There is not documentation today as it's designed for system integrators, and it's still a bit work in progress - I'm actually planning to work on it this week and I will resolve this issue and others ASAP.
I can write something for the wiki this week to help :)
Keep you informed _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
Hi William,
This is my first release (See attachment). Just a pod for the moment, statefulset for the future and perhaps helm package afterward. In my configuration i create a secret for directory manager and for certificates (not used yet) Your python code is really what i was looking for. Indeed in my previous attempts, i was stuck because i'm seeking for a way to start DS create certificate, set SSL configuration before restart the container. However in order to go futher, i would like to allow to set root password, root suffix, instance name and certificates from k8s secrets or/and configMap . To do that we need to change your current dscontainer python script and read values from variables/files (ie : see /certs folder in the container)
Waiting for your wiki on lib386 python package.
Regards
Le mer. 12 juin 2019 à 10:19, William Brown wbrown@suse.de a écrit :
On 12 Jun 2019, at 01:40, Olivier JUDITH gnulux@gmail.com wrote:
Hi,
Thank for the link , i tried to run your image but the container fails after few seconds . Seems that you forgot to create /var/run/dirsrv folder in Dockerfile .
There are some other errors in it too which I have found :)
the server crashes with : DEBUG: DEBUG: starting with ['/usr/sbin/ns-slapd', '-D',
'/etc/dirsrv/slapd-localhost', '-i', '/var/run/dirsrv/slapd-localhost.pid']
CRITICAL: Error: Failed to start DS, removing incomplete installation... Failed to connect to bus: No such file or directory Failed to connect to bus: No such file or directory Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line
654, in create_from_args
self._install_ds(general, slapd, backends) File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line
862, in _install_ds
ds_instance.start(timeout=60) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1170,
in start
raise ValueError('Failed to start DS') ValueError: Failed to start DS
It works fine now, I start to write my k8s configuration .
Fantastic - can you post to me what you are doing with k8s so I can review?
If you can just remind me where i can find documentation on lib389 used
in your dscontainer python script ?
There is not documentation today as it's designed for system integrators, and it's still a bit work in progress - I'm actually planning to work on it this week and I will resolve this issue and others ASAP.
I can write something for the wiki this week to help :)
Keep you informed _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 13 Jun 2019, at 00:12, Olivier JUDITH gnulux@gmail.com wrote:
Hi William,
This is my first release (See attachment). Just a pod for the moment, statefulset for the future and perhaps helm package afterward.
Sadly I'm not able to open your attachment - could you provide it as tar.xz or zip instead of 7z?
In my configuration i create a secret for directory manager and for certificates (not used yet) Your python code is really what i was looking for. Indeed in my previous attempts, i was stuck because i'm seeking for a way to start DS create certificate, set SSL configuration before restart the container. However in order to go futher, i would like to allow to set root password, root suffix, instance name and certificates from k8s secrets or/and configMap . To do that we need to change your current dscontainer python script and read values from variables/files (ie : see /certs folder in the container)
Actually, I'd rather read these from environment variables so that docker -e DM_PW=... works as a syntax without needing *another* config file. But yes, the ability to set these from the environment is an open issue on the project, and one I really want to look at.
There is no root suffix by default, by design, so that you have to configure one once the container is running. That's how the suffix is handled. Additionally, the instance name is static, and there is actually no benefit to allowing this to be configured, and would actually make container building harder (there are symlinks in the slapd-localhost folder of the docker image, so we assume the instance name). The instance name really really does nothing but allow human seperation, and in our case, docker is our seperation layer!
Using certs and secrets from k8s would certainly be something the python tool can work with, and would be good to have these able to do it. A better idea may be to have dscontainer take a set of PEM files and then load them to your certificate store on startup instead rather than the current method of certificate handling.
The python source is: https://pagure.io/389-ds-base/blob/master/f/src/lib389/cli/dscontainer
Waiting for your wiki on lib386 python package.
Great! I have just pushed an update to the git master dockerfile:
https://pagure.io/389-ds-base/pull-request/50441
I have updated the OBS image at docker pull registry.opensuse.org/home/firstyear/containers/389-ds-container:latest however it appears to require some code changes from master, so this will "start working" later, and we plan to start auto-building these images as network:ldap is updated in SUSE.
The wiki page is here, and I'm updating it today to include details about the dscontainer tool.
http://www.port389.org/docs/389ds/design/docker.html
Regards
Le mer. 12 juin 2019 à 10:19, William Brown wbrown@suse.de a écrit :
On 12 Jun 2019, at 01:40, Olivier JUDITH gnulux@gmail.com wrote:
Hi,
Thank for the link , i tried to run your image but the container fails after few seconds . Seems that you forgot to create /var/run/dirsrv folder in Dockerfile .
There are some other errors in it too which I have found :)
the server crashes with : DEBUG: DEBUG: starting with ['/usr/sbin/ns-slapd', '-D', '/etc/dirsrv/slapd-localhost', '-i', '/var/run/dirsrv/slapd-localhost.pid'] CRITICAL: Error: Failed to start DS, removing incomplete installation... Failed to connect to bus: No such file or directory Failed to connect to bus: No such file or directory Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 654, in create_from_args self._install_ds(general, slapd, backends) File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 862, in _install_ds ds_instance.start(timeout=60) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1170, in start raise ValueError('Failed to start DS') ValueError: Failed to start DS
It works fine now, I start to write my k8s configuration .
Fantastic - can you post to me what you are doing with k8s so I can review?
If you can just remind me where i can find documentation on lib389 used in your dscontainer python script ?
There is not documentation today as it's designed for system integrators, and it's still a bit work in progress - I'm actually planning to work on it this week and I will resolve this issue and others ASAP.
I can write something for the wiki this week to help :)
Keep you informed _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... <share.7z>_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
Hi william ,
here is a tgz
cdlt
Le jeu. 13 juin 2019 à 10:43, William Brown wbrown@suse.de a écrit :
On 13 Jun 2019, at 00:12, Olivier JUDITH gnulux@gmail.com wrote:
Hi William,
This is my first release (See attachment). Just a pod for the moment,
statefulset for the future and perhaps helm package afterward.
Sadly I'm not able to open your attachment - could you provide it as tar.xz or zip instead of 7z?
In my configuration i create a secret for directory manager and for
certificates (not used yet)
Your python code is really what i was looking for. Indeed in my previous
attempts, i was stuck because i'm seeking for a way to start DS create certificate, set SSL configuration before restart the container.
However in order to go futher, i would like to allow to set root
password, root suffix, instance name and certificates from k8s secrets or/and configMap . To do that we need to change your current dscontainer python script and read values from variables/files (ie : see /certs folder in the container)
Actually, I'd rather read these from environment variables so that docker -e DM_PW=... works as a syntax without needing *another* config file. But yes, the ability to set these from the environment is an open issue on the project, and one I really want to look at.
There is no root suffix by default, by design, so that you have to configure one once the container is running. That's how the suffix is handled. Additionally, the instance name is static, and there is actually no benefit to allowing this to be configured, and would actually make container building harder (there are symlinks in the slapd-localhost folder of the docker image, so we assume the instance name). The instance name really really does nothing but allow human seperation, and in our case, docker is our seperation layer!
Using certs and secrets from k8s would certainly be something the python tool can work with, and would be good to have these able to do it. A better idea may be to have dscontainer take a set of PEM files and then load them to your certificate store on startup instead rather than the current method of certificate handling.
The python source is: https://pagure.io/389-ds-base/blob/master/f/src/lib389/cli/dscontainer
Waiting for your wiki on lib386 python package.
Great! I have just pushed an update to the git master dockerfile:
https://pagure.io/389-ds-base/pull-request/50441
I have updated the OBS image at docker pull registry.opensuse.org/home/firstyear/containers/389-ds-container:latest however it appears to require some code changes from master, so this will "start working" later, and we plan to start auto-building these images as network:ldap is updated in SUSE.
The wiki page is here, and I'm updating it today to include details about the dscontainer tool.
http://www.port389.org/docs/389ds/design/docker.html
Regards
Le mer. 12 juin 2019 à 10:19, William Brown wbrown@suse.de a écrit :
On 12 Jun 2019, at 01:40, Olivier JUDITH gnulux@gmail.com wrote:
Hi,
Thank for the link , i tried to run your image but the container fails after few seconds . Seems that you forgot to create /var/run/dirsrv folder in Dockerfile .
There are some other errors in it too which I have found :)
the server crashes with : DEBUG: DEBUG: starting with ['/usr/sbin/ns-slapd', '-D',
'/etc/dirsrv/slapd-localhost', '-i', '/var/run/dirsrv/slapd-localhost.pid']
CRITICAL: Error: Failed to start DS, removing incomplete
installation...
Failed to connect to bus: No such file or directory Failed to connect to bus: No such file or directory Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py",
line 654, in create_from_args
self._install_ds(general, slapd, backends) File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py",
line 862, in _install_ds
ds_instance.start(timeout=60) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line
1170, in start
raise ValueError('Failed to start DS') ValueError: Failed to start DS
It works fine now, I start to write my k8s configuration .
Fantastic - can you post to me what you are doing with k8s so I can
review?
If you can just remind me where i can find documentation on lib389
used in your dscontainer python script ?
There is not documentation today as it's designed for system
integrators, and it's still a bit work in progress - I'm actually planning to work on it this week and I will resolve this issue and others ASAP.
I can write something for the wiki this week to help :)
Keep you informed _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
<share.7z>_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
Most of those look pretty reasonable. Can you describe to be the work flow and how those yaml files interacte with k8s and how they are associated to the container? Do they need to be in the docker file? Or something else?
Thanks!
On 13 Jun 2019, at 15:21, Olivier JUDITH gnulux@gmail.com wrote:
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
Of course,
Yaml files are strictly dedicated to kubernetes object definition and deployment (like deployment.yaml for service on docker). They are not to be included in docker container.
In fact the better is to create a folder "k8s" and move them into .
In order to create the container/pod on kubernetes you have to launch :
kubectl create -f 389-ds-container/kube/* with all yaml files in kube folder
In interactive mode :
kubectl run -d --name 389-ds-container --image=r egistry.opensuse.org/home/firstyear/containers/389-ds-container:latest http://registry.opensuse.org/home/firstyear/containers/389-ds-container:latest --port=3389
389-ds-container/
├── Dockerfile
├── other files/floders required for Docker image creation
└── k8s
├── 389-ds-container.yaml
├── secrets.yaml
├── service.yaml
└── storage.yaml
389-ds-container => (i made a mistake the name should be 389-ds-container.yaml) is the kubernetes pod declaration on k8s. It defines what volume, environment variables, resources limit and more required to start the container on the kube cluster. This file will use the image created and pushed on the registry of your choice
services.yaml => create a kube service which will allow external access to the pod (container). On kubernetes you can not access to you container/pod directly. You have to implement a service. In my case I created a ClusterIP which means that the service in only available inside kubernetes cluster (Can be changed) . Other modes are NodePort or LoadBalancer (available only when your k8s cluster is hosted on a CloudProvider). Service allow loadbalancing natively if you have many pods up (ie with MMR) .
Secrets.yaml => all stuff like passwords or certificates that can be defined like variable but are mounted in the pod/container and can be used like files or variables. It’s an equivalent of secret in Docker. In defined there my own fake certificate in order to inject them with certutil in the pods instead of the self-signed one
Storage.yaml => Are the definition of my volume in k8s world. I created a pv (Persistent volume) which use a physical storage type as filesystem in my case but can be another kind of storage (NFS,gluster,iscsi,FC…) the user has to provide a pv with the same name whatever the kind of storage.
Then PVC (PersistentVolumeClaim) , which wil bind the volume defined with the name and the size required.
A better idea may be to have dscontainer take a set of PEM files and then
load them to your certificate store on startup instead rather than the current method of certificate handling.
Yes i agree but if you want to read them at startup you have to provide them somewhere accessible from the container. The better i think is the secret.
Le jeu. 13 juin 2019 à 16:15, William Brown wbrown@suse.de a écrit :
Most of those look pretty reasonable. Can you describe to be the work flow and how those yaml files interacte with k8s and how they are associated to the container? Do they need to be in the docker file? Or something else?
Thanks!
On 13 Jun 2019, at 15:21, Olivier JUDITH gnulux@gmail.com wrote:
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 14 Jun 2019, at 01:25, Olivier JUDITH gnulux@gmail.com wrote:
Of course,
Yaml files are strictly dedicated to kubernetes object definition and deployment (like deployment.yaml for service on docker). They are not to be included in docker container. In fact the better is to create a folder "k8s" and move them into .
In order to create the container/pod on kubernetes you have to launch : kubectl create -f 389-ds-container/kube/* with all yaml files in kube folder In interactive mode : kubectl run -d --name 389-ds-container --image=registry.opensuse.org/home/firstyear/containers/389-ds-container:latest --port=3389
389-ds-container/ ├── Dockerfile ├── other files/floders required for Docker image creation └── k8s ├── 389-ds-container.yaml ├── secrets.yaml ├── service.yaml └── storage.yaml
389-ds-container => (i made a mistake the name should be 389-ds-container.yaml) is the kubernetes pod declaration on k8s. It defines what volume, environment variables, resources limit and more required to start the container on the kube cluster. This file will use the image created and pushed on the registry of your choice
services.yaml => create a kube service which will allow external access to the pod (container). On kubernetes you can not access to you container/pod directly. You have to implement a service. In my case I created a ClusterIP which means that the service in only available inside kubernetes cluster (Can be changed) . Other modes are NodePort or LoadBalancer (available only when your k8s cluster is hosted on a CloudProvider). Service allow loadbalancing natively if you have many pods up (ie with MMR) .
Secrets.yaml => all stuff like passwords or certificates that can be defined like variable but are mounted in the pod/container and can be used like files or variables. It’s an equivalent of secret in Docker. In defined there my own fake certificate in order to inject them with certutil in the pods instead of the self-signed one
Storage.yaml => Are the definition of my volume in k8s world. I created a pv (Persistent volume) which use a physical storage type as filesystem in my case but can be another kind of storage (NFS,gluster,iscsi,FC…) the user has to provide a pv with the same name whatever the kind of storage. Then PVC (PersistentVolumeClaim) , which wil bind the volume defined with the name and the size required.
Do you think there is value in upstreaming these? Can they be made generic? Or is this a per-site kind of configuration and needs customisation?
A better idea may be to have dscontainer take a set of PEM files and then load them to your certificate store on startup instead rather than the current method of certificate handling.
Yes i agree but if you want to read them at startup you have to provide them somewhere accessible from the container. The better i think is the secret.
Okay - how does the content of secrets.yaml get sent to the process running in the container?
There are two primary use cases here remember - both atomic/transactional server to run 389 (ie vanilla docker), and of course, k8s. So I'd prefer to re-use or share mechanisms if possible.
Is there also a way in k8s that when an event occurs (IE a new container is launched in a pod) that a program can be called in existing containers? (This way we can automate replica addition/removal)
Primarily my first goal has been to make 389 work for atomic/transactional server, because this is easy, and matches the way many peopl would run 389 today. k8s was always a future goal due to the deeper level of automation needed, and the "opinionated" nature of k8s. So I want to support both though :)
Le jeu. 13 juin 2019 à 16:15, William Brown wbrown@suse.de a écrit : Most of those look pretty reasonable. Can you describe to be the work flow and how those yaml files interacte with k8s and how they are associated to the container? Do they need to be in the docker file? Or something else?
Thanks!
On 13 Jun 2019, at 15:21, Olivier JUDITH gnulux@gmail.com wrote:
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
Is there also a way in k8s that when an event occurs (IE a new container is launched in a pod) that a program can be called in existing containers? (This way we can automate replica addition/removal)
What I'm planning to do is to use readiness probes, which can be scripts, to handle dynamic configuration of replicas. I haven't seen any way that enables existing containers to know when a new container has been launched or an old container deleted.
Regards, Aravind G
From my understanding readiness operates when the pod starts. If it doesn't reach the replica your pods will never initialize. An option (for k8s) can be another container (in the pod) "389-ds-headless" which will do all the steps required to enable replication.
Okay - how does the content of secrets.yaml get sent to the process
running in the container? By files or by variables but are always present in the container.
To enable replicas , k8s provides StatefullSet controller which is better to manage multiple instances/replication.
Regards
Le lun. 17 juin 2019 à 13:57, aravind gosukonda arabha123@gmail.com a écrit :
Is there also a way in k8s that when an event occurs (IE a new container
is launched in a
pod) that a program can be called in existing containers? (This way we
can automate
replica addition/removal)
What I'm planning to do is to use readiness probes, which can be scripts, to handle dynamic configuration of replicas. I haven't seen any way that enables existing containers to know when a new container has been launched or an old container deleted.
Regards, Aravind G _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 17 Jun 2019, at 16:25, Olivier JUDITH gnulux@gmail.com wrote:
From my understanding readiness operates when the pod starts. If it doesn't reach the replica your pods will never initialize. An option (for k8s) can be another container (in the pod) "389-ds-headless" which will do all the steps required to enable replication.
Okay - how does the content of secrets.yaml get sent to the process running in the container?
By files or by variables but are always present in the container.
To enable replicas , k8s provides StatefullSet controller which is better to manage multiple instances/replication.
Is there some documentation on this I could have a look at? It would be good for me to understand to help advise on this, because dynamic scaling of replicas is something I'd really love to see supported in k8s and upstream so we can provide a really good experience for people :)
I think it's time for me to setup k8s at home again to learn this .....
Regards
Le lun. 17 juin 2019 à 13:57, aravind gosukonda arabha123@gmail.com a écrit :
Is there also a way in k8s that when an event occurs (IE a new container is launched in a pod) that a program can be called in existing containers? (This way we can automate replica addition/removal)
What I'm planning to do is to use readiness probes, which can be scripts, to handle dynamic configuration of replicas. I haven't seen any way that enables existing containers to know when a new container has been launched or an old container deleted.
Regards, Aravind G _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
You can read more here
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
Le mar. 18 juin 2019 à 10:44, William Brown wbrown@suse.de a écrit :
On 17 Jun 2019, at 16:25, Olivier JUDITH gnulux@gmail.com wrote:
From my understanding readiness operates when the pod starts. If it doesn't reach the replica your pods will never initialize. An option (for k8s) can be another container (in the pod)
"389-ds-headless" which will do all the steps required to enable replication.
Okay - how does the content of secrets.yaml get sent to the process
running in the container?
By files or by variables but are always present in the container.
To enable replicas , k8s provides StatefullSet controller which is
better to manage multiple instances/replication.
Is there some documentation on this I could have a look at? It would be good for me to understand to help advise on this, because dynamic scaling of replicas is something I'd really love to see supported in k8s and upstream so we can provide a really good experience for people :)
I think it's time for me to setup k8s at home again to learn this .....
Regards
Le lun. 17 juin 2019 à 13:57, aravind gosukonda arabha123@gmail.com a
écrit :
Is there also a way in k8s that when an event occurs (IE a new
container is launched in a
pod) that a program can be called in existing containers? (This way we
can automate
replica addition/removal)
What I'm planning to do is to use readiness probes, which can be
scripts, to handle dynamic configuration of replicas. I haven't seen any way that enables existing containers to know when a new container has been launched or an old container deleted.
Regards, Aravind G _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
Okay, that looks really good. I read this and the example setup instructions they have.
Something I missed was a way to coordinate or notify into a running container about the creation of another one. For example, we have ldap-0 and ldap-1, we need to notify ldap-0 that ldap-2 was just brought online (or taken offline). Did I miss how to trigger an event like this?
As usual, do you think there would be value in upstream providing template yml files for this kind of setup/configuration?
Thanks!
On 18 Jun 2019, at 11:12, Olivier JUDITH gnulux@gmail.com wrote:
You can read more here
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
Le mar. 18 juin 2019 à 10:44, William Brown wbrown@suse.de a écrit :
On 17 Jun 2019, at 16:25, Olivier JUDITH gnulux@gmail.com wrote:
From my understanding readiness operates when the pod starts. If it doesn't reach the replica your pods will never initialize. An option (for k8s) can be another container (in the pod) "389-ds-headless" which will do all the steps required to enable replication.
Okay - how does the content of secrets.yaml get sent to the process running in the container?
By files or by variables but are always present in the container.
To enable replicas , k8s provides StatefullSet controller which is better to manage multiple instances/replication.
Is there some documentation on this I could have a look at? It would be good for me to understand to help advise on this, because dynamic scaling of replicas is something I'd really love to see supported in k8s and upstream so we can provide a really good experience for people :)
I think it's time for me to setup k8s at home again to learn this .....
Regards
Le lun. 17 juin 2019 à 13:57, aravind gosukonda arabha123@gmail.com a écrit :
Is there also a way in k8s that when an event occurs (IE a new container is launched in a pod) that a program can be called in existing containers? (This way we can automate replica addition/removal)
What I'm planning to do is to use readiness probes, which can be scripts, to handle dynamic configuration of replicas. I haven't seen any way that enables existing containers to know when a new container has been launched or an old container deleted.
Regards, Aravind G _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
Not quite the same, we have done completely hands-free deployments to cloud instances using `terraform`. Part of that automation was an additional tool we wrote, `replform`, which handles the automation of replication.
Like `terraform`, it is declarative, ie, you describe the desired end state in a configuration file (we normally stored it in a `git` repo), and it examines the current state, coming up with a "plan" for for the actions that need to be taken to achieve it (eg, create repman, configure replica, add agreements, perform initialization, etc.): https://github.com/bozemanpass/replform
While it can be run "globally" to configure all the replication partners in one swoop, when using it with `terraform` we normally have run as the last step of the initial setup, and then frequently as cronjob, in both cases only making changes to the local server. That way each server is responsible for only its end of the bargain as instances are added or removed, which would limit the damage if a bad configuration change were pushed.
Again, while this was all using terraformed VMs, there would be a substantial amount of overlap when using containers.
On 18 Jun 2019, at 22:25, Thomas Lackey telackey@bozemanpass.com wrote:
Not quite the same, we have done completely hands-free deployments to cloud instances using `terraform`. Part of that automation was an additional tool we wrote, `replform`, which handles the automation of replication.
Like `terraform`, it is declarative, ie, you describe the desired end state in a configuration file (we normally stored it in a `git` repo), and it examines the current state, coming up with a "plan" for for the actions that need to be taken to achieve it (eg, create repman, configure replica, add agreements, perform initialization, etc.): https://github.com/bozemanpass/replform
While it can be run "globally" to configure all the replication partners in one swoop, when using it with `terraform` we normally have run as the last step of the initial setup, and then frequently as cronjob, in both cases only making changes to the local server. That way each server is responsible for only its end of the bargain as instances are added or removed, which would limit the damage if a bad configuration change were pushed.
Again, while this was all using terraformed VMs, there would be a substantial amount of overlap when using containers.
I have heard of someone in Australia who did something similar with terraform. I can not remember their git repo though. It sounds very interesting though!
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
389-users@lists.fedoraproject.org
-
aravind gosukonda -
Olivier JUDITH -
Thomas Lackey -
William Brown