This is Ankit, your friendly DevOps content curator. I read a lot of articles about DevOps, distributed systems, performance monitoring, etc. I will be sharing some key takeaways from these articles with you so that you can stay updated and learn a few things quickly.🙂
This was a fantastic read from google's cloud architecture center.
Link to the full article👇
Best Practices for building containers
Containers are meant to be treated as a single app, and not as a virtual machine. The best practice is to have a parent process and all its child processes as a single container. If you have multiple apps in a single container, you might end up with a running container with an unresponsive core component.
Linux signals control the lifecycle of processes inside a container. And to tightly link the lifecycle of your app to its container, your app needs to handle Linux signals properly. One of the ways it can be done is by using a specialized init system like tini.
Docker build cache can be used for accelerating the building of container images by skipping potentially costly steps. To take full advantage of Docker build cache, the build steps that change often should be positioned at the bottom of the Dockerfile. Docker could use its build cache only if all previous build steps used it.
To protect your apps, try reducing the attack surface of your app by removing all unnecessary tools. For example, you can remove utilities like netcat.
Small images are suited for faster upload and download times. A few ways to ensure the small size of the image includes:
- using the smallest base image possible
- reducing the amount of clutter by installing only what is needed, and
- creating images with common layers.
In case of vulnerabilities, the best practice is to rebuild the image and its patches and redeploy it. You can choose a service to constantly scan your images for security vulnerabilities. Docker has partnered with Snyk to provide the vulnerability scanning service.
It is advised to properly link the tagging system on container images to the release policy of your software. A coherent and consistent tagging policy must be set in place and documented so that users can easily understand it.
I hope you enjoyed this TL;DR summary and learned something new. I will be coming up with more such notes soon. So, stay tuned! 🙂
Currently building SigNoz - an open-source APM & observability tool 💙
SigNoz helps developers monitor their applications & troubleshoot problems, an open-source alternative to DataDog, NewRelic, etc. 🔥 🖥
Monitor your applications and troubleshoot problems in your deployed applications, an open-source alternative to DataDog, New Relic, etc.
SigNoz helps developers monitor applications and troubleshoot problems in their deployed applications. SigNoz uses distributed tracing to gain visibility into your software stack.
- Application overview metrics like RPS, 50th/90th/99th Percentile latencies, and Error Rate
- Slowest endpoints in your application
- See exact request trace to figure out issues in downstream services, slow DB queries, call to 3rd party services like payment gateways, etc
- Filter traces by service name, operation, latency, error, tags/annotations.
- Aggregate metrics on filtered traces. Eg, you can get error…