These are the slides of a session I gave at EMEA Red Hat Tech Exchange 2017, a gathering of all Red Hat solution architects and consultants across EMEA. It is about considerations and good practices when creating images that will run on OpenShift. Available as blog at: https://developers.redhat.com/blog/2017/10/11/container-images-openshift-part-1-objectives/
7. 7
GOALS
Agile Standard Operating Environment
Common OS, libraries, application
servers, configuration
➔ Time and cost reduction for setup and
maintenance
➔ Known, expected and supportable
environment
➔ Compliance made easy
➔ Easier to staff Operating
System
Application
Libraries
Configuration
SOE
12. 12
GOALS
Resilient
The container and application should
report to the orchestration layer their:
●
Readiness to process queries
●
Own health
The container and application should:
●
Gracefully shutdown on a SIGTERM
SELF HEALING!
17. 17
STRATEGIES
Image source
Not everything is an inverted tree!
Image source provides multiple
dependencies / inheritance
●
Keep dependencies in a central point
●
Share them across images at build time
REUSABLE!
MAINTAINABLE!
18. 18
STRATEGIES
Docker build
Defined through a Dockerfile
●
Support for inheritance
●
Flexible “poor” batch like syntax
●
On or out of OpenShift
●
Dependencies should be provided as
part of the build context.
19. 19
STRATEGIES
S2I build
Build logic provided by the builder image
●
Sources either from git or streamed
to the builder image
●
Build scripts configurable through
environment variables
●
Configuration files or custom scripts
can be injected from sources repo
source build binary build
S2I
20. 20
STRATEGIES
S2I vs docker build
Aspect Docker build S2I
User switch between
users
UID defined in the
image
Rights security hazard
(multi-tenancy)
rights controlled by
UID
Image
layers
one per line a single additional
layer
Ease of
use
dockerfile
syntax required
simple configuration
OPENSHIFT
21. 21
STRATEGIES
S2I vs docker build
Docker builds
●
Provide to “super users” the flexibility
for creating base images
S2I
●
Factory for creating SOE compliant final
images in a secure and repeatable way
OPENSHIFT
22. 22
STRATEGIES
Ansible container
Similar to traditional virtual machines or
bare-metal
●
Describe the application in a single
YAML file
●
Reuse existing Ansible content
●
Uses docker engine, Kubernetes or
OpenShift under the hood
23. 23
STRATEGIES
Buildah
OCI / docker containers in a snap
●
Does not require a runtime → no special
privilege required
●
Support OCI and docker format
●
Mount a working container’s root file
system for manipulation
●
Full bash power
●
No tooling required inside the container
24. 24
STRATEGIES
Which distro?
A key choice for a supported lifecycle
Considerations
●
Architecture
●
Security
●
Testing
Options
●
Traditional: RHEL / Debian
●
Light: Atomic / Alpine
●
Distroless / Go statically linked binaries
By
25. 25
STRATEGIES
Separate build and runtime images
Build time:
●
Build tool: maven, gradle, etc.
●
Compiler: GCC, JDK, etc.
●
Credentials for accessing libraries
EFFICIENT!
SECURE!
30. 30
GUIDELINES
Documentation
Document your images
● Provide templates for easy consumption
● Use metadata / labels / maintainer information
● Expose important ports
● Expose volumes
● Set environment variables (JAVA_HOME for instance)
32. 32
GUIDELINES
Processes
Design considerations
● Avoid multiple processes inside a single container
● Collocate inside a pod if required (shared network and storage for comm.)
● Use systemd if it has to be
➔ OpenShift monitors one process
➔ Signal handling is easier
33. 33
GUIDELINES
Security
Mind the following
● Avoid sshd (docker / oc exec can be used instead)
● Avoid sudo (unpredictable TTY and signal-forwarding behavior)
● Support arbitrary user ids (NSS wrapper can be used for user mapping)
● Avoid setting default passwords
34. 34
GUIDELINES
Security (2)
And the following
● Keep your image up-to-date (use OpenSCAP for monitoring vulnerabilities)
● GPG sign your images
● Limit the attack surface with run time only images
35. 35
GUIDELINES
Base images
When you create a base image
● Don’t reinvent the wheel use FROM
● Use volumes for persistent data, emptyDir and make read only everything else
● Provide file and directory access through gid 0
● Do not listen on ports under 1024
● Synchronize timezone
● Consider squashing
36. 36
GUIDELINES
Base images (2)
When you create a base image
●
Provide common libraries in base images (size vs reuse)
●
Allow extension points at build and run time
●
Use env variables and mounts for run time configuration
●
Adapt to resources CPU / RAM
37. 37
GUIDELINES
Static content
Where should you pack static content?
Depending on whether the release process for static content is bound to the
application image you may:
●
Rebuild the image and use image sourcing for code / content segregation
●
Mount a network share with it at run time
38. 38
GUIDELINES
Docker specifics
In your Dockerfile:
●
Avoid yum update (not idempotent)
●
Chain commands in a line for single layer creation
●
Clean temporary files (in the same line)
●
Mind the order of the instructions (most stable at the top)
●
Have a user statement at the end (prefer UIDs rather than user names)
●
Don’t use docker commit (not reproducible)
39. 39
GUIDELINES
Builder images
Things to consider with builder images
●
Enable image for S2I
●
Remember the golden image strategy and provide the possibility to inject
environment specific configuration at run time
●
Pre-populate repositories (maven) used during builds for quicker processing
●
Repeatable: Control the environment
●
Give a thought on clustering aspects
40. 40
GUIDELINES
Builder images (2)
External builds
●
Support streaming artifacts into the S2I image
●
Support retrieving versioned artifacts from a company repository
●
Support packaging pre-built artifacts into the image
41. 41
GUIDELINES
Run time images
Things to consider with run time images
●
Limit the attack surface (as mentioned in regard of security)
●
Write logs to standard output (not file system)
●
Provide liveness, readiness probes
●
Support graceful shutdowns
●
Use exec in wrapper scripts
