New feature : switch config profile about s6-overlay

[jprjr]

@azhuang I think this is a pretty neat idea. I could see this being useful to maybe turn off debugging-type features.

[glerchundi]

@azhuang first of all, thanks for contributing :-)

I think this is a very good idea but I'm not pretty sure if this is necessary to include in our overlay. There are several ways to achieve the same behaviour:

1. Create one container per profile: myimage:v1-dev, myimage:v1-staging, myimage:v1-production
2. Use one image but make different folders available in each execution. For example, docker run -v``pwd``/dev/cont-init.d:/etc/cont-init.d myimage:v1, docker run -v``pwd``/staging/cont-init.d:/etc/cont-init.d myimage:v1 or , docker run -v``pwd``/prod/cont-init.d:/etc/cont-init.d myimage:v1
3. Your option, check it in runtime and use them accordingly.

I would bet for the second choice because:

• It doesn't overcomplicate the init process
• Better granularity. It allows you to override just one of them.
• Related to the previous but it allows you to share configs between profiles and it requires you to just create one docker image.
• It keeps everything simple for the end-user.

But this would require removing 00-runscripts from /etc/fix-attrs.d and embed its content inside the init process, as it is part of the system-wide init process.

WDYT?

[azhuang]

@jprjr @glerchundi

Well your inputs reminds me something a little off-topic. We really should put all user configurables into one directory so that we can bind mount all scripts at once. Currently we can't mount /etc because mount behaves like it will replace all contents from its mounting point. Besides user scripts in cont-init.d cont-finish.d services.d, 00-runscripts should be included as well.

Yes I think 00-runscripts should be part of init process. It is vital to overlay and end-user may override this file by mistake, especially when it is mounted into container along with other user scripts.

My implementation is actually not a must but an option. If S6-CONTAINER-PROFILE is not set, the switching process will be skipped (when original /etc/cont-init.d will be used). It is backward compatible so that end-user can update to new version without modifying configs. BTW, one profile doesn't have to include cont-init.d cont-finish.d. The services.d is a bit tricky, s6-svscan will report error if services.d is symlinked to a directory that doesn't exist. (I have made a simple fix, but I'd like to rewrite it according to how we organize user scripts.)

[glerchundi]

Well your inputs reminds me something a little off-topic. We really should put all user configurables into one directory so that we can bind mount all scripts at once. Currently we can't mount /etc because mount behaves like it will replace all contents from its mounting point.

Not necessarily:

This would share services and will mount just the required ones for each environment:

dev (hook init and finish):

docker run \
  -v `pwd`/dev/cont-init.d:/etc/cont-init.d \
  -v `pwd`/dev/cont-finish.d:/etc/cont-finish.d \
  myimage:v1

prod (do nothing probably it already contains everything production-ready):

docker run myimage:v1

Besides user scripts in cont-init.d cont-finish.d services.d, 00-runscripts should be included as well.

Yes I think 00-runscripts should be part of init process. It is vital to overlay and end-user may override this file by mistake, especially when it is mounted into container along with other user scripts.

Yep. Done in #78.

My implementation is actually not a must but an option. If S6-CONTAINER-PROFILE is not set, the switching process will be skipped (when original /etc/cont-init.d will be used).

Right, but it allows you to do the same in so different ways that it can be confusing.

It is backward compatible so that end-user can update to new version without modifying configs.

Of course and it's the right way to do the things :-)

BTW, one profile doesn't have to include cont-init.d cont-finish.d.

But now sharing between profiles is a little bit more complicated:

/etc/cont-profile.d/base
  - /cont-init.d
  - /cont-finish.d
  - /services.d
/etc/cont-profile.d/dev
 - /cont-init.d
 - /cont-finish.d
 - /services.d -> /etc/cont-profile.d/base/services.d
/etc/cont-profile.d/prod
 - /cont-init.d -> /etc/cont-profile.d/base/cont-init.d
 - /cont-finish.d -> /etc/cont-profile.d/base/cont-finish.d
 - /services.d -> /etc/cont-profile.d/base/services.d
[...]

Or something like this.

The services.d is a bit tricky, s6-svscan will report error if services.d is symlinked to a directory that doesn't exist. (I have made a simple fix, but I'd like to rewrite it according to how we organize user scripts.)

It's hiercopied to /var/run first and then s6-svscan is used there so it shouldn't be a problem if it's its probably because it's a bug :-)

That being said, we can include this behaviour inside the init process without promoting it anywhere because I'm not quite sure what is my opinion on this. I feel like I'm violating some rules on lean containers, like deviating from what people is doing right now.

Create a rebased PR and we'll discuss there.

[glerchundi]

Although I mistakenly closed the #81 PR, it's already pushed into the master. And a new version is on the way: v1.14.0.3.