In a previous article, I introduced a simple way to perform system checks with pytest + testinfra . Here it is a simple variant of the same principle with the intention of producing a short human readable report about system configuration. The goal is to get and report quickly some value of interests from a system (a host).
I did not know the Linux install command before.
This install program copies files (often just compiled) into destination locations you choose.
Let’s see how it can be useful.
The with statement in Python allows the execution of a block of code inside a context manager responsible of the initialization and the finalization code. It is often used in the standard library and one of the most frequent usage is for interacting with files. The context manager is responsible of the file lifecycle: initialization code is responsible of opening the file while the finalization code is responsible of closing it. It’s common and convenient to use with statement, but it can be interesting to define our own implementation for dedicated tasks like running a Docker container. Let’s check how to do it.
Recently big outages have occurred impacting two of the main cloud vendors
highlighting the importance of a process dedicated to analyse the incidents or outage in the aim of knowing what happened and why, but above all to learn and take appropriate actions in order to avoid the same problems to occur again. This process is called postmortem — or post mortem in two words.
Here is a short but very useful tip to avoid committing unwanted files by configuring a gitignore at global level. The main advantage is that it’s configured once for all and you don’t have to do it on each project.
How does one get the size of a Docker image before they pull it to their machine?
When it comes to perform customization to startup scripts in order to initialize or tune something, it’s not obvious to pick the right startup file. The way the system is reading startup files depends on the context and mainly if the shell is
When packages are installed in a Dockerfile through APT (Debian, Ubuntu) you should comply with some best practices.
One of the main reason is to try to keep the image as as small as possible, but it’s not the only one.
Let’s examine a typical snippet of package’s installation.
Sample startup files are traditionally kept in
/etc/skel. If you customize your systems' startup file examples,/usr/local/etc/skelis a reasonable place to put the modified copies.1
Recently I had to use the R test framework called testthat. I noticed that this framework is very human oriented. Its name comes from the way to write tests that aims to make a readable sentence.
After my recent article on marking deprecated code in R, I had the same problem on R data package. Unfortunately I was not able to find a convenient out-of-the-box solution, see this question on SO.
So after a first draft, I’ve applied a process that seems to be a reasonable–good enough–solution.
By using the same fun analysis as in my previous article, I would like too highlight a problem that often occurs, dealing with too much categories (or factors as they are called in R) avoid to see clearly the big pictures.
When working with data it’s very important to be aware of the unit of each variable. To make it explicit it’s convenient to use the package called units.
In the frame of the Hackaviz2020 organized by the ToulouseDataViz, I had to work on displaying weekends on a plot. And, this is not so easy for a novice …
I was wondering the effect of merging layers (squashing) on the size of an image. Now Docker provides an experimental --squash option for the build.
You might be saying to yourself, “but I have rootless containers right now with Docker - I run my docker commands as a regular user and it works all the time.” Even though you are executing the docker command line tool without root, the docker daemon is executing those requests as root on your behalf […]
After my previous article on zombie processes I was curious to see if and how they can affect containers running in a Kubernetes (K8S) cluster.
The first step is an orphaned process, a process that has lost his parent.
Suppose the parent process terminates, either intentionally (because the program logic has determined that it should exit), or caused by a user action (e.g. the user killed the process). What happens then to its children? They no longer have a parent process, so they become “orphaned” (this is the actual technical term).
— source
