The docker files and containerization techniques to create images and manage the containers on server.
- Solution you maybe dont need day one:
- Fully automatic CI/CD
- Dynamic performance scaling
- Containering all or nothing
- Starting with persistant data
- More important than fancy orchestration
- Its your new build and environment documentation
- Study Dockerfile / ENTRYPOINT of hub Officials
- FROM official distros that are most familier
- Make it start
- Make it log all things to stdout/stderr
- Make it documented in file
- Make it work for others
- Make it lean
- Make it scale
- Latest = Image builds will be (dont know thw latest config)
- Problem : Image builds pull from latest
- Solution: Use specific FROM tags
- Problem: Image buils install latest packages
- Solution : Specify version for critical apt-/yum-/apk packages.
- Problem Not changing app defaults or blindly copying VM vonfig -e.g. php.ini, mysql.conf
- Solution : Update default config via ENV, RUN, and ENDPOINT.
- Try both
- Stick what you know first
- Do some basic performance testing
One thing : If the containers grow rapidly then runnning them on VM makes complicated and you need to start take care about kernel-network scheduling and network settings
- try Ubuntu : ;-)
- Baby Swarm: 1 Node
- Used on our laptop
- HA Swarm : 3-Node (High Availabilty)
- Minimum for HA
- All managers
- One node can fail
- Use when very small budget
- Pet projects or Test/CI
- Biz Swarm : 5-Node
- Better high availability
- All managers
- Two nodes can fail
- My minimum for uptime that affects $$$time
- Flexy Swarm : 10+ Nodes
- 5 dedicated Mangers
- Workers in DMZ
- Anyting beyond 5 nodes, stick with 5 managers and rest Workers
- Control container placement with labels +Constaints
- Swole Swarm : 100+ Nodes
- 5 dedicaed managers
- Resize Managers as you grow
- Multiple Workers subnets on Private / DMZ
- Control container placement with labels + constraints
- Assume nodes will be replaced
- Assume containers will be recreated
- Docker for (AWS/ AZURE) does this
- LinuxKit and IntraKit
Bad Reasons | Good Reasons |
---|---|
Different hardware conf | Learning : Run stuff on test swarm |
Different subnets or security groups | Geographical boundries |
Different availabilty zone | Use of Docker API |
- Image registry
- Logs
- Monitoring and alerting
- Tools/Projects : https://github.com/cncf/landscape
- Realize parts of your tech Stack may change , stay flexible