-
Notifications
You must be signed in to change notification settings - Fork 28
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
introduce docker container production #660
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
.git | ||
.gitignore | ||
.dockerignore |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,114 @@ | ||
name: Publish Docker Container Images | ||
on: | ||
push: | ||
branches: [main] | ||
|
||
env: | ||
REGISTRY: ghcr.io | ||
REPO_NAME: ${{ github.repository }} | ||
|
||
permissions: | ||
contents: read | ||
packages: write | ||
|
||
jobs: | ||
|
||
# ------------------------------------------------------------------------------------------ | ||
# To be decided: Script-Deploy or Dockerfile-Deploy: | ||
# Script: | ||
# + Separates the golang build from the corso build. | ||
# - Haven't figured out multiplatform builds yet. | ||
# - Doesn't cache, always takes 10-15 minutes per build in the matrix. | ||
# Dockerfile: | ||
# + Once cached, takes <1m to deploy. | ||
# + Multiplatform. | ||
# + Extended features (such as tagging) can be handled by more github actions. | ||
# - When not cached, can take >2 hours to build (at least initially). | ||
# - Currently includes the complete golang:1.18 image. | ||
# ------------------------------------------------------------------------------------------ | ||
|
||
Script-Deploy: | ||
runs-on: ubuntu-latest | ||
defaults: | ||
run: | ||
working-directory: build | ||
strategy: | ||
matrix: | ||
BUILD_ARCH: [amd64, arm64] | ||
BUILD_OS: [linux] | ||
env: | ||
IMAGE_PREFIX: ghcr.io | ||
VERSION_SUFFIX: rolling | ||
ryanfkeepers marked this conversation as resolved.
Show resolved
Hide resolved
|
||
steps: | ||
- name: Checkout repository | ||
uses: actions/checkout@v3 | ||
|
||
- name: Run build script | ||
run: > | ||
./build-container.sh | ||
--arch ${{ matrix.BUILD_ARCH }} | ||
--prefix ${{ env.IMAGE_PREFIX }} | ||
--suffix ${{ env.VERSION_SUFFIX }} | ||
|
||
# login step boilerplate from: | ||
# https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-ghcrio | ||
- name: Log in to registry | ||
run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u $ --password-stdin | ||
|
||
- name: Push image | ||
env: | ||
IMAGE_ID: ${{ env.IMAGE_PREFIX }}/alcionai/corso | ||
VERSION: ${{ matrix.BUILD_OS }}-${{ matrix.BUILD_ARCH }}-${{ env.VERSION_SUFFIX }} | ||
run: | | ||
docker images -a | ||
docker push ${{ env.IMAGE_ID }}:${{ env.VERSION }} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what sort of naming scheme are we going for? Looking at some of the containers on dockerhub it seems many of them use the format There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Punt: we're not pinning down the naming structure as part of this PR, instead just trying to get anything out. Likely @gmatev and others will have future concerns about that design. I'm sure it'll be some variation/combination of version|schedule|platform. On that note, we still need to set the foundation for Corso versioning semantics and release control patterns. I expect that much of the version tagging will cascade as a result of that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For image tag names the docs PR https://github.com/alcionai/corso/pull/658/files#diff-289cef99004de6fb5ad1a419ad9b4c2d491be1c7558eebfacc4ca484fd0eb58a actually has some relevant details. |
||
|
||
Dockerfile-Deploy: | ||
runs-on: ubuntu-latest | ||
env: | ||
TARGETOS: linux | ||
TARGETARCH: arm64 | ||
steps: | ||
- name: Checkout repository | ||
uses: actions/checkout@v3 | ||
|
||
# apparently everyone uses this step | ||
- name: Set up QEMU | ||
uses: docker/setup-qemu-action@v2 | ||
|
||
# setup Docker buld action | ||
- name: Set up Docker Buildx | ||
id: buildx | ||
uses: docker/setup-buildx-action@v2 | ||
|
||
# In case we want to switch to dockerhub | ||
# - name: Login to DockerHub | ||
# uses: docker/login-action@v2 | ||
# with: | ||
# username: ${{ secrets.DOCKERHUB_USERNAME }} | ||
# password: ${{ secrets.DOCKERHUB_TOKEN }} | ||
|
||
# retrieve credentials for ghcr.io | ||
- name: Login to Github Packages | ||
uses: docker/login-action@v2 | ||
with: | ||
registry: ghcr.io | ||
username: ${{ github.actor }} | ||
password: ${{ secrets.GITHUB_TOKEN }} | ||
|
||
# build the image | ||
- name: Build image and push to Docker Hub and GitHub Container Registry | ||
uses: docker/build-push-action@v3 | ||
with: | ||
context: . | ||
file: ./docker/Dockerfile | ||
platforms: linux/amd64,linux/arm64 | ||
push: true | ||
tags: ghcr.io/alcionai/corso:rolling | ||
# use the github cache | ||
cache-from: type=gha | ||
cache-to: type=gha,mode=max | ||
|
||
# check the image digest | ||
- name: Image digest | ||
run: echo ${{ steps.docker_build.outputs.digest }} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
# syntax=docker/dockerfile:1 | ||
|
||
# This dockerfile is configured to be run by the /corso/build/build-container.sh | ||
# script. Using docker to build this file directly will fail. | ||
|
||
FROM gcr.io/distroless/base-debian10 | ||
# FROM gcr.io/distroless/base:debug | ||
|
||
WORKDIR / | ||
|
||
COPY ./bin/corso ./ | ||
|
||
USER nonroot:nonroot | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's make sure we can have everything mapped from For example:
I think the simplest way is to set environment variables that specify locations (and Corso picks up) and make sure the right folders exist. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When you say There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or is this a request outside of the docker build; making sure that our system plays nicely (via defaults, etc), with the /app/corso location? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ryanfkeepers sorry this notification did not pop-up. I mean the latter. Our docs will tell you to map a local folder to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Made an issue to track it. Feel free to add/change the details there. |
||
|
||
ENTRYPOINT ["/corso"] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,29 @@ | ||
# syntax=docker/dockerfile:1 | ||
|
||
# This dockerfile is able to make a quick, local image of corso. | ||
# It is not used for deployments. | ||
|
||
## Build | ||
FROM golang:1.18 AS base | ||
|
||
WORKDIR /src | ||
|
||
COPY ./src/go.mod . | ||
COPY ./src/go.sum . | ||
RUN go mod download | ||
|
||
COPY ./src . | ||
|
||
FROM base AS build | ||
ARG TARGETOS | ||
ARG TARGETARCH | ||
RUN GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o /corso . | ||
|
||
## Deploy | ||
FROM gcr.io/distroless/base-debian10 | ||
|
||
WORKDIR / | ||
COPY --from=build /corso / | ||
|
||
COPY ./bin/corso ./ | ||
|
||
USER nonroot:nonroot | ||
|
||
ENTRYPOINT ["/corso"] | ||
ENTRYPOINT ["/corso"] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
// docker-bake.hcl | ||
target "docker-metadata-action" {} | ||
|
||
target "build" { | ||
inherits = ["docker-metadata-action"] | ||
context = "./" | ||
dockerfile = "Dockerfile" | ||
platforms = [ | ||
"linux/amd64", | ||
"linux/arm64", | ||
] | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
Dockerfile
seems reasonable - I do think we need to move thecorso
binary build out of theDockerfile
though - that is likely the slow part here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's definitely the slow part. Can you explain more about moving the binary build out of the dockerfile? I'm still trying to wrap my head around docker, and I'm not seeing how we'd pull that part out without being left with, functionally, the scripted approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scripted approach:
./build-container.sh
which internally calls./build.sh
to buildcorso
. Usesbuild/Dockerfile
"Dockerfile approach" (very similar): Uses
docker/Dockerfile
which is a variation ofbuild/Dockerfile
that buildscorso
as part of Docker build. Usesdocker/build-push-action
I'm suggesting we always use
./build.sh
as a step in the deploy to build thecorso
binary and then usebuild/Dockerfile
with thedocker/build-push-action
action to build and push the imageThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay, I made another branch to try out this combaintion:
Here's the diff.
The build result.
And the resulting image.
It mostly works. For some reason the tag isn't coming through on the docker pull. But otherwise seems to be handling it fine. Let me know if that's along the lines of what you were thinking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks about right.
./build.sh
does currently build within a container and I think for CI we want to invokego build ...
directly (and enable GO caching). That should hopefully speed things up.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried to invoke
go build ...
directly, but we're getting some cross-compilation failures with the azure libraries. Error messages can be seen here. Source seems to be this issue with CGO and cross-compilation.If you could kindly check out the rest of the changes before I fold them into this PR, they're here.