Adds a Dockerfile that creates a terragrunt image #1665
Conversation
|
fwiw, demonstrating it builds... and runs: |
There was a problem hiding this comment.
Thanks for the PR!
I could configure a Docker Hub build as you mentioned here, but there are a few gotchas:
- How do we set the version number in the binary? See my comment in the PR itself.
- How do we test the
Dockerfilebefore merging/releasing? I'd rather not merge something and later find out the Docker Hub build failed. - Docker Hub has introduced a bunch of limits recently, and seems to be heading in the direction of adding still more. Terragrunt might be popular enough to trip this limits... Not sure how many people use it via Docker though.
Dockerfile
Outdated
|
|
||
| COPY . . | ||
|
|
||
| RUN make build |
There was a problem hiding this comment.
This will end up with an empty version number in the binary. It needs to be set via:
-ldflags "-X main.VERSION=<VERSION>"
But it's not clear what version number we'd be able to use?
There was a problem hiding this comment.
The version is not empty! That's one reason I used the make build target. The version is determined by the command git describe --tags --abbrev=12 --dirty --broken. When the checkout matches a git tag, the value is just the git tag. When the checkout is not a tag, you get the last tag plus a git ref marker.
If you go with the dockerhub build service, dockerhub clones the repo and has all the tags, so this evaluates correctly. I'd expect any other container build service would also.
$ git describe --tags --abbrev=12 --dirty --broken
v0.29.2-2-gc90d385e21b8
$ git tag v0.29.3-testing
$ git describe --tags --abbrev=12 --dirty --broken
v0.29.3-testing
There was a problem hiding this comment.
For example:
$ docker run --rm gruntworkio/terragrunt --version
terragrunt version v0.29.2-3-gdbe93918437f-dirty
Dockerfile
Outdated
|
|
||
| ### | ||
|
|
||
| FROM alpine:latest |
There was a problem hiding this comment.
NIT: couldn't this be scratch? I think a standalone Go binary doesn't need anything else...
There was a problem hiding this comment.
Perhaps? Using alpine:latest and the multistage build, it's only a 40MB image. Might be over-optimizing... I'll give it a shot though.
There was a problem hiding this comment.
The scratch base image worked, just needed to use CGO_ENABLED=0. Image size is 34MB.
$ docker run --rm gruntworkio/terragrunt --version
terragrunt version v0.29.2-4-g4deae14c6db3-dirty
I addressed that inline. The version is being set!
What I usually do is build the image in CI and then run the container, exercising some suite of tests. How thorough I want to be with the image generally depends on how confident I am in the unit tests or integration tests I run more directly. Sometimes I just will run the container passing a basic flag, like
I haven't seen any DockerHub limits on building or pushing images for public projects. There are rate limits on users pulling images, and it is the user's responsibility to login to dockerhub to avoid the rate limit. There is also a plan to expire images that have not been used in 6 months, for accounts on the free tier. That seems pretty reasonable, though. If the image is being used, it remains available. If it's not used for 6 months, it seems likely it is not needed (and a user in desperate need could build it themselves at that point). |
|
@brikis98 I added a step to the circle-ci config to build the container as an example of how to validate the docker build in CI, but I have no ability to run it, of course. I also have never used circle-ci, so I may have guessed wrong about how to do this! 😬
|
|
Hey folks, |
|
Following on from @angeloskaltsikis's question, what is blocking progression on this PR? I am happy to pick up getting this merged into branch so that alpine/terragrunt at Dockerhub with over 10 million downloads can be deprecated. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for submitting this pull request. |
WalkthroughThis update introduces a Dockerfile for building and packaging the "terragrunt" Go application as a statically linked binary in a minimal container. Alongside, the CircleCI configuration is updated with a new Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant CI as CircleCI
participant Docker as Docker Engine
participant Container as terragrunt Container
Dev->>CI: Push tag (vX.Y.Z)
CI->>CI: Run unit_test & integration_test
CI->>Docker: Build Docker image (terragrunt-test)
Docker->>Container: Run container (output terragrunt version)
Container-->>Docker: Return version string
Docker-->>CI: Pass/fail based on version check
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
Dockerfile (4)
1-5: Great use of multistage build—but consider future‐proofing the Go version.
Pinning togolang:1.16.3-alpineworks today, but Go 1.16 is in maintenance mode and may miss out on performance/security updates. You could introduce a build ARG likeARG GO_VERSION=1.16.3and useFROM golang:${GO_VERSION}-alpine as builder. That makes bumping easier later without editing the Dockerfile directly.
9-11: Nice layer caching for Go modules.
Separatinggo.mod/go.sumandgo mod downloadis spot on for faster rebuilds when source changes but deps don’t. One tiny nit: consider usinggo mod verifyafter download to ensure module integrity.
13-15: Solid build step—but lock down your build environment.
You’ve gotCGO_ENABLED=0 make build, which yields a static binary. To guarantee it always targets amd64 Linux, you might also setGOOS=linux GOARCH=amd64(unless your Makefile already does). Example:-RUN CGO_ENABLED=0 make build +RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 make buildThat way there’s no surprise if someone builds on a different host arch.
19-23: Scratch final image—impressively tiny!
Usingscratchensures minimal attack surface. One thought: since it runs as root by default, you might add a non‐root user in the builder andUSERin the final stage (though static binaries typically don’t need passwd entries). Also, consider a simpleHEALTHCHECKto validate the binary still responds over time..circleci/config.yml (1)
70-75: Version check looks solid!
Usinggit describe --tagsand grepping the container’s output is an effective smoke test. One tweak: wrap$vtag_maybe_extrain quotes in thegrepto avoid globbing surprises if the tag has special characters. E.g.:- docker run --rm terragrunt-test --version | grep $vtag_maybe_extra + docker run --rm terragrunt-test --version | grep -F -- "$vtag_maybe_extra"This guards against regex interpolation and makes the grep intention obvious.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.circleci/config.yml(2 hunks)Dockerfile(1 hunks)
🔇 Additional comments (2)
.circleci/config.yml (2)
63-69: Good start on abuild_containerjob—don’t forget publishing.
You build theterragrunt-testimage locally, but there’s nodocker push. If you rely on Docker Hub Automated Builds or another registry, that’s fine. Otherwise, add a push step or document how the image will be published.
111-119: Workflow integration is clear—just verify ordering.
You’ve wiredbuild_containerto run after tests, parallel tobuild. Confirm that you’re happy if a container‐build failure doesn’t blockdeploy. If you’d like to gate deployments on a working container too, consider addingbuild_containeras a requirement fordeploy.
Related to #1655
Summary by CodeRabbit
New Features
Chores