GitLab Continuous Deployment Docker Kaniko DevOps

GitLab as your Continuous Deployment one-stop shop

This week, I want to take a break from my Start Rust series and focus on a different subject. I’ve already written about my blogging stack in detail. However, I didn’t touch into one facet, and that facet is how I generate the static pages from Jekyll. As I describe in the blog post, I’ve included quite a couple of customizations. Some of them require external dependencies, such as: A JRE for PlantUML diagrams generationThe graphviz package for the same reasonetc. All in all

Docker container Jekyll Ruby

Musings around a Dockerfile for Jekyll

If you like cool stories about how an engineer, faced with an impossible problem, overcame all odds and solved it, this post is not for you. This is a story of how I spent a non-trivial amount of time, how I hit a couple of walls, and how I nearly came back to square one. Why do I write it? The first reason is for me: I want to document my journey so if I ever think about trying again in the future, I’ll have some arguments against it. Second, in opposition to the actual zeitgeist, you le

Docker design

Composition over inheritance applied to Docker

This post is neither a recommendation, nor even a suggestion. It’s just me toying with an idea: Implement it at your own risk! The main benefit of Docker containers is that they are self-contained. For developers, that means one just needs to inherit from the desired Docker image that contains the necessary required dependencies, and presto, one can build one’s application deliver it to production. Most of the times, the process is pretty straightforward. Containerization allows

Docker industrialization ONBUILD

ONBUILD, the overlooked Docker directive

It’s hard to ignore Docker nowadays. There are a lot of blog posts available on the Web. The problem is that most always repeat the same. In this post, I’d like to focus on one directive that I find overlooked via a use-case: it is Java specific, but the parallel can be easily drawn to other tech stacks. The problem The situation is the following: as a developer, I’d like to use Docker as a way to package a JAR from the sources of my application. As a reminder, here’

Docker optimization Gemfile npm

Layering your Docker images with dependencies

Since already some years, this site uses the Jekyll static site generator. Generating the complete site takes about 15 minutes. Some time ago, I decided to setup Gulp to minimize HTML in order to speed up page view for readers. This change added about 10 minutes to the build time, for a total of ~25 minutes, which is a long time…​ too long. I wanted to decrease the build time, so I decided to play around. The initial state A Docker image is used to build the site. The image is bas

webapp Docker Spring Boot

Distributing desktop webapps via Docker

Two weeks ago, we studied how to replace desktop Java apps with Java webapps. Now is the time to think about distributing such desktop webapps. The current trend now is to use Docker. I assume readers are at least familiar with the technology. The most straightforward way is to create a WAR and deliver it inside a Tomcat image. Another option is to create a fat JAR with Tomcat embedded as per the previous post, and run it inside a image with the JRE only. One of the deciding factors is the si

maven build Docker maintenance

Truly immutable builds

It sometimes happen that after a few years, an app is stable enough that it gets into hibernating mode. Though it’s used and useful, there are no changes to it and it happily runs its life. Then, after a while, someone decides to add some new features again. Apart from simple things such as locating the sources, one of the most important thing is to be able to build the app. Though it may seem trivial, there are some things to think about. Here are some advices on how to make apps that can