I create a lot of compose file that I hope are useful for the community.
I'd like to find a way for docker to officially ship these compose files.
There is one issue that IMHO is blocking us of doing so, is the ability to ship a file in docker-compose.
Indeed, what distinguish a piwik
from an ownCloud
from a WordPress
compose file is only the nginx configuration.
There are 3 way that I know to ship this configuration:
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
web:
image: nginx
volumes:
- ./data:/var/www/html
command: |
bash -c 'bash -s <<EOF
cat > /etc/nginx/nginx.conf <<EON
daemon off;
user www-data;
events {
worker_connections 768;
}
http {
gzip on;
gzip_disable "msie6";
include /etc/nginx/mime.types;
server {
listen 80;
root /var/www/html;
index index.html;
}
}
EON
nginx
EOF'
A bit dirty
web:
image: nginx
volumes:
- ./data:/var/www/html
files:
- owner: root:root
path: /etc/nginx/nginx.conf
permissions: '0644'
content: |
user www-data;
events {
worker_connections 768;
}
http {
gzip on;
gzip_disable "msie6";
include /etc/nginx/mime.types;
server {
listen 80;
root /var/www/html;
index index.html;
}
}
And so, I'm sure you see the value to have a proper way to add inline file.
The syntax could be similar to what cloudinit does.
With this, it would become easier to ship one compose file with everything included to get started an app!
Would also help not over-engineering something. I have to use Docker configs for snippets of configuration when really it would be easier/portable in a single YAML file.
So for configs you could have something as follows:
version: '3.3'
services:
postgresql:
image: postgresql
configs:
- target: /postrgresql_config
uid: '103'
gid: '103'
mode: 0440
content: |
myconfig: $(YOU)
value: $(CAN)
other: $(TEMPLATIZE)
@shin- Hi, any solution ?
@Fridus Check out https://github.com/docker/app !
Issue grooming: I think I agree with @shin- that this sounds more like a docker-app thing.
Most helpful comment
Would also help not over-engineering something. I have to use Docker configs for snippets of configuration when really it would be easier/portable in a single YAML file.
So for configs you could have something as follows: