haufe-lexware / docker-style-guide Goto Github PK

[Rainer Kempkes]

Haben wir eigentlich sowas wie ein Docker-App-Template mit ein paar Basics wie einem reverse proxy container, einem Data volume container und zentralem Logging Container, auf dem man dann seine business logic reincontainern kann? Hätt ich gut gebrauchen können...

See api-style-guide readme.md

Going via http://htmlpreview.github.io/?https://raw.githubusercontent.com/Haufe-Lexware/docker-style-guide/gh-pages/index.html, and selecting any subpage triggers a download vs rendering in html.

From Torben Knerr @tknerr_de
@hlgr360 @HaufeDev this looks better, but all the links are still broken (not present on the gh-pages branch):

Probably considerable overlap with other raised issues

We have a set of docker security guidelines from Amir we started from but obviously since then gained some better understanding of what works and what doesn't

Our docker image repo is our artifactory. Artifactory is used both as docker image repo and as build package repo .. meaning if you build your application (Maven?) your should be using Artifactory as transparent proxy between your internal build chain and any external component repo. During your build process Artifactory will cache any modules you pull from a public repo and scan it for vulnerabilities. Subsequent pulls can then be resolved through the cached and ‘locked-in’ version held locally in Artifactory,

This prevents us from being exposed to repo poisoning attacks where malicious code could be inserted in a public repo and inserted in dependent projects by virtue of building them.

We need to be able at any point i time to build a production deployment of X with verified components without the need of an external repo, be it npm, or maven or ‘god-knows-what’. Artifactory as transparent proxy to any public repo will give us this assurance.

Once your CI has finished, you push the docker build into Artifactory. Again we scan for vulnerabilities automatically, If its clean, you can use your CD pipeline to deploy it into production.

Your docker images can be derived from validated images from verified vendors on docker hub. In general that tends to be repos in the root _ namespace of docker hub. Docker has transitioned to use Alpine as base image.

https://www.brianchristner.io/docker-is-moving-to-alpine-linux/
https://hub.docker.com/_/alpine/

Since you are asking for OpenJDK .. there appears to be an official build for that as well
https://hub.docker.com/_/openjdk/

Verified or official docker hub account are labelled as such (labeled official and placed in the root _ namespace - you can use docker pull openjdk in that case - hence the reference to namespace) and are curated and validated by a dedicated team at Docker.

https://docs.docker.com/docker-hub/official_repos/

So in general your CI/CD will split conceptually between two distinct phases …
(1) the source to image build process: the image being generated and pushed into artifactory
(2) the image repo to deployment process: the image being pulled from artifactory and deployed into production

What I am missing is a TOC or a set of jumping off links in the README ... right now if I look at the repo, the README is standalone and does not guide me towards the initial chapters.

Look at https://github.com/Haufe-Lexware/api-style-guide for an example.

We need to document the process to get an account to the internal docker repo at Artifactory (plus internal Go.CD pipeline) vs the external Haufe docker hub account and the external Go.CD pipeline

Here is the snippet from an email explaining the process (from @DonMartin76):

Build on commit and push image into docker.hub for the OSS one? Does it end there + a demo compose file?
Yup, that’s how it works. If you check in and push to github, it automatically builds and pushes to docker hub, given the tests still work, obviously. If no changes are detected, it builds once a week.

Maybe we also need in here or in a seperate document to describe both the jenkins and the go.cd CI/CD pipelines for building and deploying docker images (incl. Examples)

Describe acceptable use of images from public repos
trusted base vs trusted
can we build from public repos, etc pp