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

Apigee provider is not working in alpine-based docker containers #48

Closed
zkauker opened this issue Nov 15, 2019 · 5 comments
Closed

Apigee provider is not working in alpine-based docker containers #48

zkauker opened this issue Nov 15, 2019 · 5 comments

Comments

@zkauker
Copy link
Contributor

zkauker commented Nov 15, 2019

Hi there,

I'm working on setting up CI/CD pipeline on Gitlab that uses hasicorp/terraform:light docker image to execute terraform configurations. In the before_script my pipeline downloads the official release of apigee provider and extracts that into the ~/.terraform.d/plugins/linux_amd64 directory.

terraform init succeeds, but terraform plan results in what you can see below. If I build the provider binary on my mac and use that one in the terraform container it works well.

After looking around I came across this issue which put me in the right direction in my investigations. The key difference between the two builds is that building with goreleaser on mac results in a statically-linked binary, while the official release built by travis is dynamically linked for linux_amd64 architectures:

~ # file terraform-provider-apigee_v0.0.19.local
terraform-provider-apigee_v0.0.19.local: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=OpakQujwE-isFRYk06PL/6f6v6kbuTUO8EP-DmtMZ/yJe5Sp1_znQHmpRLusLP/9QtMOuLasAU1RcvsFyyc, stripped
~ # file terraform-provider-apigee_v0.0.19.official
terraform-provider-apigee_v0.0.19.official: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=6bnRxkSsmPZdWr2bD-d1/sFbduLa_Q7qT7wnshCay/pOweN8Bat3p0xb-uEWp6/6n2vJaN7B1H_jmylOWYx, stripped

When you cross-compile go, the CGO is disabled and thus, the binary will use static linking. However, travis is on linux_amd64, so when you build a binary for the same architecture CGO will be enabled and the build binary will be dynamically linked. In alpine-based images you don't have all the glibc libraries, which results in the failure you can see below.

Suggestion:
As the builds for Mac and Windows platforms are statically linked anyway, it would make sense to disable CGO in the goreleaser configuration to build statically-linked binary for linux platform as well. The size of the binary will increase by cca. 1.5MB (23.7 -> 25.2), but this will enable users to use the official builds in official hasicorp/terraform docker images.

Terraform Version

Terraform v0.12.15

Affected Resource(s)

all

Terraform Configuration Files

irrelevant

Debug Output

2019-11-14T16:56:17.325Z [DEBUG] plugin: starting plugin: path=/root/.terraform.d/plugins/linux_amd64/terraform-provider-apigee_v0.0.19 args=[/root/.terraform.d/plugins/linux_amd64/terraform-provider-apigee_v0.0.19]
170 Error: Failed to instantiate provider "apigee" to obtain schema: fork/exec /root/.terraform.d/plugins/linux_amd64/terraform-provider-apigee_v0.0.19: no such file or directory
174 ERROR: Job failed: exit code 1

Expected Behavior

The provider can be started.

Actual Behavior

The provider cannot be started

Steps to Reproduce

Install the official build of apigee provider into an alpine-based docker container and try to use a terraform configuration that uses apigee provider.

zkauker pushed a commit to zkauker/terraform-provider-apigee that referenced this issue Nov 15, 2019
@zambien
Copy link
Owner

zambien commented Nov 15, 2019

Oh boy. Linking with Alpine can be a pain. Are you certain that by disabling dynamic linking the plugin will function in Alpine? I have had some experience with this in other repos and sometimes the best solution is to use a multistage build Dockerfile as follows for Alpine:

# ****************************************************************************************
# ******** Create a dev environment to build alpine tf plugins and build them *********
# ****************************************************************************************
FROM alpine:latest as build
# Setup the alpine build environment for golang
RUN apk add --update alpine-sdk
RUN apk update && apk add go git gcc musl-dev linux-headers

WORKDIR /app

COPY go.mod .
COPY go.sum .

# Get deps - will also be cached if we won't change mod/sum
RUN go mod download

COPY  / .
RUN mkdir -p /app/bin \
	&& GO111MODULE=on CGO_ENABLED=1 GOOS=linux go build -a -i -o /app/bin/terraform-provider-apigee . \
	&& sha256sum -b /app/bin/terraform-provider-apigee > /app/bin/SHA256SUMS

# ***********************************************************
# ********** This is our actual released container **********
# ***********************************************************
FROM alpine:latest
WORKDIR /app
COPY --from=build /app/bin/terraform-provider-apigee /terraform-provider-apigee
COPY --from=build /app/bin/SHA256SUMS /SHA256SUMS
# Test the binary is executable
RUN /terraform-provider-apigee || true # prevent non-zero return code

The Dockerfile above works so I can PR it in but I'd like your thoughts on this approach vs. the one you recommended.

@zkauker
Copy link
Contributor Author

zkauker commented Nov 15, 2019

@zambien I've just sent you a PR and described how I tested that. But if you have concerns with that just let me know, I just wanted to avoid using custom docker images. And I think enabling the provider to work in a lightweight terraform container like official one would be nice!

@zambien
Copy link
Owner

zambien commented Nov 15, 2019

Sounds good to me. Released. Thanks for the contribution!

@zambien zambien closed this as completed Nov 15, 2019
@zkauker
Copy link
Contributor Author

zkauker commented Nov 15, 2019

awesome, great thanks!

@zkauker
Copy link
Contributor Author

zkauker commented Nov 15, 2019

@zambien just want to confirm that the new release fixed the issue. Thank you much!

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

No branches or pull requests

2 participants