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

Docker compose cleanup #325

Merged
merged 2 commits into from
Mar 2, 2020
Merged

Docker compose cleanup #325

merged 2 commits into from
Mar 2, 2020

Conversation

KarthikNayak
Copy link
Contributor

Related issue

#324

Proposed changes

Cleanup the existing docker-compose.yml and add a new Dockerfile-dc

Checklist

  • I have read the contributing guidelines
  • I have read the security policy
  • I confirm that this pull request does not address a security
    vulnerability. If this pull request addresses a security vulnerability, I
    confirm that I got green light (please contact
    [email protected]) from the maintainers to push
    the changes.
  • I have added tests that prove my fix is effective or that my feature works
  • I have added necessary documentation within the code base (if appropriate)
  • I have documented my changes in the
    developer guide (if appropriate)

@claassistantio
Copy link

claassistantio commented Dec 30, 2019

CLA assistant check
All committers have signed the CLA.

@ducharmemp
Copy link

I believe that this might also need a volume mount at $HOME/.oathkeeper.json or something like that? I'm actually in the process of trying to figure out how to set up my API access rules now and struggling with the fact that the full-stack example is also out of date.

I suppose another solution would be to build another image based off of oathkeeper with my config options, but that feels a bit heavy handed.

If the docker-compose isn't meant as an example just ignore me :)

@KarthikNayak
Copy link
Contributor Author

@ducharmemp I'll leave that decision to @aeneasr, currently this docker-compose uses the built in .schemas folder.

@aeneasr
Copy link
Member

aeneasr commented Jan 2, 2020

Thank you, there is no need for any type of mounting. We're using packr as part of the build process to embed these files, as you can see here: https://github.com/ory/oathkeeper/blob/master/Makefile#L50-L56

Please update the docker image accordingly :)

@KarthikNayak
Copy link
Contributor Author

@aeneasr I've updated the PR, do have a look! :D

Dockerfile-dc Outdated
ADD . /app
WORKDIR /app
RUN go get -u github.com/gobuffalo/packr/v2/packr2
RUN CGO_ENABLED=0 GO111MODULE=on GOOS=linux GOARCH=amd64 packr2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

packr2 does not need these arguments - see the makefile for reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would still need the GO111MODULE=on argument, this ensures that packr2 doesn't build the boxes as per the path instead of the modules.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, that makes sense. You can set ENV GO111MODULE on in the dockerfile so go modules are enabled for all commands

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, we could do that too!


ADD . /app
WORKDIR /app
RUN go get -u github.com/gobuffalo/packr/v2/packr2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are using a fixed version of packr2, GO111MODULE=on go install github.com/gobuffalo/packr/v2/packr2 should be enough - see the makefile for reference

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do!

Dockerfile-dc Outdated
@@ -0,0 +1,21 @@
FROM alpine:3.10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use golang:1.13-alpine instead. You don't need golang:latest then

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, will change that!

@@ -1,25 +1,10 @@
version: '2'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file needs more work - there is for example no config file being loaded. The environment variables also seem to be outdated

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, will check and add it!

@KarthikNayak
Copy link
Contributor Author

Just an FYI, got busy with life, picking this up again!

@aeneasr
Copy link
Member

aeneasr commented Jan 29, 2020

All good, happens to the best of us :)

@KarthikNayak
Copy link
Contributor Author

@aeneasr You mentioned some of the ENV variables to be deprecated, I tried following https://www.ory.sh/docs/oathkeeper/configure-deploy, but the documentation seems to be outdated here too (it talks about using a DB, which we no longer require). Is there a more recent updated version of the documentation?

@aeneasr
Copy link
Member

aeneasr commented Jan 30, 2020

Regarding docs, it was a bug that was introduced two days ago. It was resolved today so everything should be up to date again! :)

Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, that looks much better now! Unfortunately, I still have some feedback:

  1. Please remove the (probably commited by accident) oathkeeper binary
  2. Adding config files as part of the Docker Image is bad practice. While it would be ok for demo purposes, it's important that we work with best practices because a lot of people are looking at the stack for guidance. Adding config files (such as private keys) to a Docker Image exposes them effectively to anyone that can pull the image, which is why this is not supposed to be done like that. I've added comments how to address this in the PR.

Dockerfile-dc Outdated

COPY --from=0 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=0 /app/oathkeeper /usr/bin/oathkeeper
COPY --from=0 /app/.docker_compose/config.yaml config.yaml
Copy link
Member

@aeneasr aeneasr Feb 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I said in the summary comment, adding config files as part of the build process is bad practice. Let's remove these. I've created another image for another project which makes use of volumes to mount the config. It uses a standard alpine-based image with a custom user: https://github.com/ory/kratos/blob/master/.docker/Dockerfile

Then, we simply mount the folder where the config files are at and use the �config flag to define where the config files is saved.

I think a 1:1 copy should work more or less for oathkeeper too. The cool thing is, hot reloading will work! So you can edit your config file on the host and oathkeeper will reload it!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I'm just wondering if there's a better way to even add the private keys. I've made the changes you've suggested here.

Dockerfile-dc Outdated
RUN packr2
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build

FROM scratch
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can use the alpine-based image here, as people might want to docker exec into it to debug or whatever. That way, they'll have a shell available!

Check out another docker image that uses an alpine-based linux and adds a user ory. I'd recommend doing something similar: https://github.com/ory/kratos/blob/master/.docker/Dockerfile

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got rid of the multistage multi image Docker and using golang:1.13-alpine

Add a new file 'Dockerfile-dc' which will primarily be used by Docker Compose to
build docker images. Unlike the existing Dockerfile which depends on the Makefile
to build the binary, this Dockerfile copies the source code and builds the
binary.

Copied from: https://github.com/ory/kratos/blob/master/.docker/Dockerfile

Signed-off-by: karthik nayak <[email protected]>
Oathkeeper has gone through a couple of changes since the initial draft of the
docker compose file, considering these changes and the newly introduced
Dockerfile in the previous commit, make these changes to the docker-compose.yml:
1. Bump the version of the compose file to 3.
2. Remove the need for the postgres database app, since Oathkeeper no longer needs a
database.
3. Remove the need for the migration app, since we no longer need to migrate since
there is no database and the option is deprecated.
4. Use the newly defined Dockerfile 'Dockerfile-dc'.
5. We now serve both API and PROXY from the same app, so we don't need two
instances of the app.
6. Add sample config, rules and JWK files to `.docker_compose`, mount this via a
volume mount.

Signed-off-by: karthik nayak <[email protected]>
Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late reply and thank you for your awesome work! Good job!

@aeneasr aeneasr merged commit 1247381 into ory:master Mar 2, 2020
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.

4 participants