Docker official image

[Olivier JUDITH]

Hi all, 

Do you provide an official docker image for 389 ?
I plan to deploy MMR on Kubernetes .
Any advice/link ?

[William Brown]

>  On 10 Jun 2019, at 23:42, Olivier JUDITH <gnulux(a)gmail.com&gt;
> 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-contai...

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[William Brown]

>  On 11 Jun 2019, at 09:37, William Brown <wbrown(a)suse.de&gt;
> wrote:
>  
>  
>  
> > On 10 Jun 2019, at 23:42, Olivier JUDITH <gnulux(a)gmail.com&gt; 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-contai...
>  
>  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(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  
>  —
>  Sincerely,
>  
>  William Brown
>  
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Olivier JUDITH]

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

[William Brown]

>  On 12 Jun 2019, at 01:40, Olivier JUDITH <gnulux(a)gmail.com&gt;
> 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Olivier JUDITH]

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(a)suse.de&gt; a écrit :

>  > On 12 Jun 2019, at 01:40, Olivier JUDITH <gnulux(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>
>  —
>  Sincerely,
>
>  William Brown
>
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>

[William Brown]

>  On 13 Jun 2019, at 00:12, Olivier JUDITH <gnulux(a)gmail.com&gt;
> 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(a)suse.de&gt; a écrit :
>  
>  
>  > On 12 Jun 2019, at 01:40, Olivier JUDITH <gnulux(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  
>  —
>  Sincerely,
>  
>  William Brown
>  
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  <share.7z>_______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Olivier JUDITH]

Hi william ,

here is a tgz

cdlt

Le jeu. 13 juin 2019 à 10:43, William Brown <wbrown(a)suse.de&gt; a écrit :

>  > On 13 Jun 2019, at 00:12, Olivier JUDITH <gnulux(a)gmail.com&gt; 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(a)suse.de&gt; a écrit :
>  >
>  >
>  > > On 12 Jun 2019, at 01:40, Olivier JUDITH <gnulux(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  > > To unsubscribe send an email to
>  389-users-leave(a)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/[e-mail]...
>  >
>  > —
>  > Sincerely,
>  >
>  > William Brown
>  >
>  > Senior Software Engineer, 389 Directory Server
>  > SUSE Labs
>  > _______________________________________________
>  > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  > <share.7z>_______________________________________________
>  > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>
>  —
>  Sincerely,
>
>  William Brown
>
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>

[William Brown]

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(a)gmail.com&gt;
> wrote:
>  
>  _______________________________________________ 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Olivier JUDITH]

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:l...
--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(a)suse.de&gt; 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(a)gmail.com&gt; wrote:
>  >
>  > _______________________________________________
>
>  —
>  Sincerely,
>
>  William Brown
>
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>

[William Brown]

>  On 14 Jun 2019, at 01:25, Olivier JUDITH <gnulux(a)gmail.com&gt;
> 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(a)suse.de&gt; 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(a)gmail.com&gt; wrote:
>  > 
>  > _______________________________________________
>  
>  —
>  Sincerely,
>  
>  William Brown
>  
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[aravind gosukonda]

>  
>  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

[Olivier JUDITH]

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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>

[William Brown]

>  On 17 Jun 2019, at 16:25, Olivier JUDITH <gnulux(a)gmail.com&gt;
> 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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Olivier JUDITH]

You can read more here

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

Le mar. 18 juin 2019 à 10:44, William Brown <wbrown(a)suse.de&gt; a écrit :

>  > On 17 Jun 2019, at 16:25, Olivier JUDITH <gnulux(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  > _______________________________________________
>  > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>
>  —
>  Sincerely,
>
>  William Brown
>
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>

[William Brown]

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(a)gmail.com&gt;
> wrote:
>  
>  You can read more here
>  
>  https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
>  
>  Le mar. 18 juin 2019 à 10:44, William Brown <wbrown(a)suse.de&gt; a écrit :
>  
>  
>  > On 17 Jun 2019, at 16:25, Olivier JUDITH <gnulux(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  > _______________________________________________
>  > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  
>  —
>  Sincerely,
>  
>  William Brown
>  
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Thomas Lackey]

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.

[William Brown]

>  On 18 Jun 2019, at 22:25, Thomas Lackey
> <telackey(a)bozemanpass.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs