-
-
Notifications
You must be signed in to change notification settings - Fork 361
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
Conversation
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 :) |
@ducharmemp I'll leave that decision to @aeneasr, currently this docker-compose uses the built in |
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 :) |
@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 |
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.
packr2
does not need these arguments - see the makefile for reference.
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.
Will do!
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.
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.
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.
right, that makes sense. You can set ENV GO111MODULE on
in the dockerfile so go modules are enabled for all commands
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.
Yup, we could do that too!
|
||
ADD . /app | ||
WORKDIR /app | ||
RUN go get -u github.com/gobuffalo/packr/v2/packr2 |
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.
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
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.
Will do!
Dockerfile-dc
Outdated
@@ -0,0 +1,21 @@ | |||
FROM alpine:3.10 |
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.
Use golang:1.13-alpine
instead. You don't need golang:latest
then
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.
Alright, will change that!
@@ -1,25 +1,10 @@ | |||
version: '2' |
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.
This file needs more work - there is for example no config file being loaded. The environment variables also seem to be outdated
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.
Alright, will check and add it!
Just an FYI, got busy with life, picking this up again! |
All good, happens to the best of us :) |
@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? |
Regarding docs, it was a bug that was introduced two days ago. It was resolved today so everything should be up to date again! :) |
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.
Thank you, that looks much better now! Unfortunately, I still have some feedback:
- Please remove the (probably commited by accident)
oathkeeper
binary - 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 |
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.
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!
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.
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 |
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.
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
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.
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]>
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.
Sorry for the late reply and thank you for your awesome work! Good job!
Related issue
#324
Proposed changes
Cleanup the existing docker-compose.yml and add a new Dockerfile-dc
Checklist
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.
developer guide (if appropriate)