Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Opinion] Migrate to docker compose file version 3 and without extends, to support swarm deployment. #208

Open
obayit opened this issue Jan 12, 2021 · 5 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@obayit
Copy link

obayit commented Jan 12, 2021

I thing it would be nice if the copier template is compatible with docker swarm out of the box.

Currently docker swarm requires a compose file of version 3.0 or higher, and it also doesn't support the extends key.

@obayit obayit changed the title [Opinion] Migrate to docker compose file version 3 and without extend to support swarm deployment. [Opinion] Migrate to docker compose file version 3 and without extends to support swarm deployment. Jan 12, 2021
@obayit obayit changed the title [Opinion] Migrate to docker compose file version 3 and without extends to support swarm deployment. [Opinion] Migrate to docker compose file version 3 and without extends, to support swarm deployment. Jan 12, 2021
@yajo
Copy link
Contributor

yajo commented Jan 13, 2021

This never happened before because we didn't have a proper templating tool as we do today. It would be nice indeed.

@yajo yajo added enhancement New feature or request help wanted Extra attention is needed labels Jan 13, 2021
@obayit
Copy link
Author

obayit commented Feb 26, 2021

Hi @yajo , I started working on this, by using macros.
For example, this macro is for volumes:

{%- macro common_yaml_odoo_volumes() %}
    volumes:
      - filestore:/var/lib/odoo:z
{%- endmacro %}

, I started working on this, by using macros.
For example, this macro is for volumes:

{%- macro common_yaml_odoo_volumes() %}
    volumes:
      - filestore:/var/lib/odoo:z
{%- endmacro %}```

Then I use it in common.yaml like this:

services:
  odoo:
    ...
    {{ macros.common_yaml_odoo_volumes() }}

I plan to make a macro for every key like volumes and then use it in devel.yaml, prod.yaml and test.yaml.
Am I going in the right direction?```
Then I use it in common.yaml like this:

services:
  odoo:
    ...
    {{ macros.common_yaml_odoo_volumes() }}

I plan to make a macro for every key like volumes and then use it in devel.yaml, prod.yaml and test.yaml.
Am I going in the right direction?
Edit: fixed code block syntax

@yajo
Copy link
Contributor

yajo commented Feb 26, 2021

It seems some of your macros broke your comment 😋

For what I can understand, if I were to use macros, I think common.yaml would disappear. For the rest, I guess you're right.

@gdgellatly
Copy link

I've kind of done this, although not using copier. In then end using a .env file like the old scaffolding just made more sense for the compose files.

I'd recommend having common.yaml -> docker-compose.yml, in .gitignore ignore docker-compose.override.yml and unignore docker-compose.yml, then just have 3 override files, linking for each environment. invoke develop then just links the test override file to be docker-compose.override.yml

@yajo
Copy link
Contributor

yajo commented Oct 5, 2021

It could be an option too. Although given Copier can generate any files and repeat any code comfortably, maybe the best would be to just generate those 3 environments completely and statically, allowing freedom for further overrides if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants