terraform-provider-docker

terraform-provider-docker copied to clipboard

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Would be nice to add compose support. https://github.com/docker/compose-cli is a new binary that supports compose fomat, it has a lot of usefull things like json output. Thanks

New or Affected Resource(s)

• docker_compose

Potential Terraform Configuration

resource "docker_compose" "foo" {
  raw    =  file("${path.module}/docker-compose.yaml)"
  environment = [] 
  masked = [] -> masked environments
}

environment and masked comes from docker-compose --env-file , masked are marked as sensitive

References

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days. If you don't want this issue to be closed, please set the label pinned.

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days. If you don't want this issue to be closed, please set the label pinned.

Is there any traction on this? I note the previous incarnation of this request at https://github.com/hashicorp/terraform-provider-docker/issues/85 where the suggestion was to write a "translator" tool to translate the YAML of a docker-stack.yml into appropriate Terraform HCL for this particular provider.

I'm learning myself towards the latter, but if there's already work being done to directly support the Docker Compose YAML directly in this provider, that may work for us too.

There are multiple ways to implement this:

1. We simply take the docker-compose.yaml from the user and pass it on to the docker-compose cli. The advantage is, that we can keep it simple, the implementation will be quick and we can rely on the docker-compose cli to do all the heavy lifting. Disadvantage is, that the user has to have the docker-compose cli installed and that we cannot support all the different commands from the cli

2. We implement docker-compose as a seperate provider. This is definitely a lot of work but would allow us to keep things seperate between the two providers.

3. Wrap the docker-compose go client and implement all the calls/data structures. Also a lot of work.

I am currently favouring Option 1, due to its simplicity. Any thoughts from the community?

FWIW, docker-compose is now deprecated in favor of docker compose.