Skip to content

Create Dockerfile #64

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

alexjplant
Copy link

@alexjplant alexjplant commented Dec 20, 2024

👋 Hey everybody! I'm using LocalStack as part of a Docker Compose setup. As part of this effort I've whipped up a simple Dockerfile so that I can use terraform-local in the same fashion as Hashicorp's official Terraform image to apply Terraform after LocalStack spins up via depends_on and healthchecks. I pushed this to my own Dockerhub for the time being but it'd be great to have an upstream version. Happy to coordinate with you all on this and help in any way that I can; this probably needs a GH Action workflow and an official Dockerhub repo on top of what I have here.

@alexrashed
Copy link
Member

Hi @alexjplant! This is pretty interesting! Could you please elaborate on how you are using this Docker image in your setup / workflow?

@alexjplant
Copy link
Author

alexjplant commented Dec 20, 2024

Sure! I have a Docker Compose file that spins up localstack as a service with a healthcheck that tests for its endpoints being available. I then have a service that depends on it (i.e. starts once it's available) that runs the terraform-local image that I built. The terraform-local service mounts a volume with the Terraform to be applied to localstack services and runs tflocal apply. Ordinarily I'd do this with the official terraform image but it lacks the Python script in this repo to build the localstack specific overrides. This arrangement makes it so that a fellow developer can git clone my project and simply do a docker compose up to get rolling; IMO this is much easier than jumping through pip and brew hoops to get things installed. It also has the added benefit of being as ephemeral as possible so that you don't have to worry about state in between runs.

localstack's value proposition is making AWS development tighter/easier and I think my use case takes this one step further :-). Let me know how I can help or if you have any other questions.

@alexjplant
Copy link
Author

@alexrashed Any thoughts on this?

@alexrashed
Copy link
Member

This is an interesting use case, but it's a bit problematic for us to implement. We would have to push a lot of different images with every release of tflocal (namely with all supported terraform versions in it).
Out suggested way to initialize state using terraform is to use a specific extension terraform-init. We have a tutorial on how to use it in our docs. Would this help in your case? However, LocalStack Extensions are currently a Pro-only feature.

If not, how would you propose to solve the issue with the different terraform versions?

@alexjplant
Copy link
Author

It doesn't seem like tflocal has any specific version parity with Terraform so that removes at least one variable from the equation... for what it's worth it seems as though Terraform releases every ~quarter and only supports the two most recent versions. This could be accommodated by further parameterizing the Terraform version in my Dockerfile so that multiple arches (as well as versions as things are presently) can be built in CI.

The Pro feature might help but unfortunately we haven't procured Pro at work and there doesn't seem to be any zeal for such from my perspective. Still happy to help in any way I can on this effort - I await your response.

@alexrashed
Copy link
Member

tflocal is basically compatible with nearly all versions of terraform, but yes, we could limit the supported versions for the Docker images to the ones supported by terraform.
But we would still have to build a release pipeline for this, which creates at least 4 images: tflocal for the last two terraform versions for ARM64 + AMD. The Dockerfile would have to build tflocal from source though (instead of the current install from PyPi).
We don't really need versioning for the Docker images in the initial version, so I guess we could just publish latest images.
Do you think you could provide a GitHub workflow which performs these builds + DockerHub pushes?

@alexjplant
Copy link
Author

Sounds good. I'll take a look at your all's existing GH Actions workflows and see if I can whip something up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants