DevNexus was back in person in April 2022! I had the chance to get there and take some notes listening to the talks there.
Contents
Container Usage Patterns by Raju Gandhi
To begin with, some handy command lines
1 2 3 |
docker system prune would not remove volumes #don't forget to use -a --volumes to prune everything docker run --network mynet --name devnexus #the dns name devnexus will be resolved by other containers in the same network |
Did you know you can use digests to be fully deterministic
1 |
FROM ubuntu@sha256:xxxx |
Trade off being that you won’t get updates you’d get relying on tags such as ubuntu:22.10 (regularly rebuilt)
A good idea is to use LABELs; some of them are actually standardized.
Most of the time, you’d want to use constants in your labels, such as:
1 |
LABEL org.opencontainers.image.authors:Anthony |
but a very nice usage is to add at the end of your Dockerfile some dynamic values to help your consumers:
1 2 3 4 |
ARG BUILD_DATE ARG GIT_REF LABEL org.opencontainers.image.created:BUILD_DATE LABEL org.opencontainers.image.version:GIT_REF |
It could be useful to use sidecar processes in Docker containers:
1 |
cid=$(docker run -d nginx) && docker run -it --pid=$cid alpine sh |
would allow the original nginx container to survive even if the process would die.
It’s not only pid though; you can share multiple types of resources across different containers; including pid, memory, volumes.
Another example of usage is sharing memory to make sure you don’t wipe the memory of a process, attaching it to another long running container
Carefull craft your .dockerignore
To filter the build context, making sure you don’t include your .git folder and other files / folders in your production image.
Always have your process be pid #1 , using array style CMD[« java », « main.class »]
You can style use an entrypoint.sh
, but make sure the process your start (java -jar, npm start, etc.) is forced as PID #1, exec
in linux can help you with that/
Docker tools:
- Use dive to explore the layers of your Docker image; convenient to check you did not un necessary many files / folders
- Hadolint: it’s a Dockerfile linting tool, to enforce best practices such as specify WORKDIR before relative path COPY
- Trivy: to check the potential CVEs in your Docker image
Removing complexity from integration tests using Testcontainers! by Oleg Šelajev
Microservices testing is difficult: not many unit tests
TestContainers provides an api to control Docker in Java, Scala, NodeJS, Go, Rust
It’s mature: it’s on the thoughtworks technology radar.
There already exists several modules to control postgresql, rabbitmq, etc. If not, it’s easy to use GenericContainer.
And if you want to mock a rest api, you can also use MockServer in conjunction with TestContainers.
The demo was performed using spring boot, it’s available at: https://github.com/testcontainers/workshop
Some tools
- Kubescape: to test security in a kubernetes cluster.
- kubeseal : for secrets
- securityheaders probely, : to test a website for its CORS and CSPs
- implicitdetector.io: to test a website for its wrong usage oa OAuth2 implicit flow
- dependabot for github; there is an equivalent with Gitlab.
- github.com/pyrsia : it’s a distributed binary distribution network – Zero-Trust Decentralized Package Network
Some concepts
- Shift Left: testing and security measures into code development processes early
- https://minimumcd.org/minimumcd/ and the great presentation from Bryan Finster and Istvan Bathazi
- Continuous Delivery book
- CAB compliance : change approval board.
- QA should be async – not on the path of the pipeline