Comments (5)
@azhuang I think this is a pretty neat idea. I could see this being useful to maybe turn off debugging-type features.
from s6-overlay.
@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:
- Create one container per profile: myimage:v1-dev, myimage:v1-staging, myimage:v1-production
- 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
- 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?
from s6-overlay.
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.)
from s6-overlay.
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.
from s6-overlay.
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.
from s6-overlay.
Related Issues (20)
- systemd notify service conversion exmaple HOT 4
- s6-notifyoncheck: fatal: s6-supervise not running. HOT 3
- Installing S6 on official php-fpm container shows no log output from S6 HOT 5
- Issue with s6-overlay in Cattr project when deployed on Kubernetes HOT 6
- `UID not set` error HOT 10
- Question: pass args to the underlying service HOT 6
- s6-overlay v3 only sends SIGTERM to `/etc/services.d` after `S6_SERVICES_GRACETIME` HOT 8
- Setting S6_READ_ONLY_ROOT does not copy `/etc` to `/run/s6/etc` HOT 3
- Service is started, but reported as "normally down", seemingly by default HOT 11
- 3.1.6.1 hangs at the very end of shutdown for more than a minute HOT 3
- In some rare occasions s6-overlay hangs at shutdown for undefined amount of time HOT 4
- Using s6-overlay with ECS Exec HOT 8
- How to create something similar like cont-init if this one is deprecated ? HOT 3
- Best practice for redirecting output from app1 to app2 HOT 5
- Problem using S6_STAGE2_HOOK to run shell script HOT 2
- s6-linux-init: warning: parent wrote to fd 3! HOT 9
- How to read ENV variables from a file for the main process (defined in CMD) HOT 4
- Shutdown container during s6-rc startup leads to deadlock HOT 3
- finish script does not receive system.exit code but 0 HOT 33
- Cannot make Log to stdout work with s6-overlay 3.1.6.2 (no bug, just looking for some guidance/help). HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from s6-overlay.