REDUCE THE SIZE OF YOUR BUILDER IMAGES
Docker images should have a small size. For example, Alpine Linux images have a mere 50MB of size, debian-slim is 50-60MB of size. Why do we seek a small size footprint? One reason is simply because the docker images are usually pushed to, and download from, docker repositories like dockerhub or other private docker repositories. Use a small base image Alpine and debian-slim-stable are like 50MB. Use these kind of images instead of bigger images.
DON'T BE PERCIVAL
Percival is a mythologic figure, a mighty knight associated with King Arthur, the knights of the round table, and the search for the grail. How is the myth related with starting working in a new team? The myth In Chrétien De Troyes’ poem The Story of the Grail, Percival, a young boy that dreams of becoming a knight lives in a farm with his mother. He descends from a long tradition of knights (his deceased father and grandfather were knights) but he does not know. His mother keeps him in the dark about this, fearing that knowing his roots would make he more likely to follow the steps of his father, and hence face some dangers and die.
FAIL FAST AND OFTEN
Being fail-tolerant is valued in organizations as in a changing world where requirements, technologies or even team members can change from one day to the next, having adaptative capacities is gold. Wait, what are you talking about? I am talking about having the ability to prioritize our work as developers. Everything has not the same importance and our resources are finite. You have to know what is the aim of your organization. Are you working for a well-positioned big company that is looking the excellence in its products? Or are you working for a startup that is trying to create the product as fast as possible?
OVERRIDE DOCKER-COMPOSE.YML FILES
Sometimes we want to have different versions of docker-compose.yml files (one for production and one for development). Each environment has their own characteristics (slightly different images for example) we show here a good way to override sections of a docker-compose.yml file easily. Why? Sometimes we have several environments that share almost all docker configuration. Having a common docker-compose.yml file and several docker-compose.override.yml files is a great way to manage your service configurations.
ACTUAL INTEGRATION TESTS
Many times we have some piece of code that is tested but is still failing in production. How is that possible? Is that because of bad tests or we have a greater hidden issue? Integration tests are the best way make sure that a functionality does not degradate when adding new features. What are integration tests Integration tests are tests that check a full feature of the project. So, in the case of adding new features, we can guarantee that at least the covered features are going to keep working as expected.
ADD CHANGES TO YOUR LAST COMMIT
Have you ever created a commit with a meaningful message and, later wanted to add or modify something to it? And what about if you pushed that commit? Here we are going to see how you add changes to a commit, independently of if it was pushed or not. How-to Let’s suppose we have just pushed a commit and we want to add another change to it. This process is called amend.
REWRITE GIT BRANCH HISTORY
Ever had a pushed branch that is completed and ready for review but the git history is too long and full of commits wit. How to The process is very clear. You only have to get the changes, move your point to the branch you want to merge (usually master), unstage everything, creating new committs, and force push the changes. Let us see the process step by step: Revert all your commits Assuming you are in a branch and want to do a clear history with respect to the master branch, the first step is doing:
EYESONLY
Secrets are usually involuntary leaked by developers. Sometimes they are sent to external services like or written in a log by accident. Would not be useful to have a tool to limit the access to secrets? Enter EyesOnly: a package to limit access to secrets Dealing last years with containerazing applications has left me thinking in how we are passing some secrets as environment variables to the container. This is standard practice by the Cloud Native practitioners. However, once you pass an environment variable you fall in two different issues:
ALLOW WRITING OF FILES IN DOCKER IN LINUX
I have been working on a small project in Python: functainer. The goal of this project is to provide a Python package to run functions in docker seamlessly: you only will docker and Python to run it. Anyway, that project uses files as a mean of communication, i.e. there is a file volume that the container uses to write the output, and make it reachable by the host. When the host is a Linux machine, docker daemon runs on root user, and that user is not the same than yours (obviously). A way to avoid having a Permission Denied error is to run your container with your user y making use of –user parameter in the docker container run command, e.g.:
ASKING AND RECEIVING FEEDBACK ON YOUR SOFTWARE PROJECT
Introduction A month ago I asked the HN Community for some feedback about my project: Gelidum. The experience was very positive and I have learned that asking for feedback in a software project is crucial. Why feedback is important? We know that feedback is important because it gives us a different point of view about a matter or in my case, a project. But, feedback is not limited to giving different points of view. You can receive ideas, suggestions or even some personal experience. All of this information gives you an advantage when choosing what the next step is going to be. Seeing what others have done, what’s the state of the art or if some feature is missing can make you pivot your project and steer it in a more adequate direction.