Move daily emails into the blog page
This commit is contained in:
parent
be69398931
commit
1b8441608f
828 changed files with 9 additions and 196 deletions
23
source/_posts/2023-04-18.md
Normal file
23
source/_posts/2023-04-18.md
Normal file
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
title: >
|
||||
Consistency is key
|
||||
pubDate: 2023-04-18
|
||||
permalink: >-
|
||||
daily/2023/04/18/consistency-is-key
|
||||
tags:
|
||||
- automation
|
||||
- devops
|
||||
- docker
|
||||
---
|
||||
|
||||
A side effect of [using a tool to generate build configuration files]({{site.url}}/daily/2023/03/04/why-i-built-a-tool-to-generate-configuration-files) with templates is the consistency that it introduces.
|
||||
|
||||
The majority of my projects use a PHP-FPM or PHP CLI container. In my Docker Compose file, the service was mostly named `php` but sometimes it was `php-fpm`. In the templated file, it's always named `php`.
|
||||
|
||||
Some projects would use `mysql` or `mariadb` for the database service and `nginx` or `caddy` depending on which server was being used. These are now always `database` and `web` respectively.
|
||||
|
||||
As well as being easier to switch between projects and not having to think about which names are used in each codebase, it's also much easier to write tools and automation when the names are consistent.
|
||||
|
||||
For example, I'd always write a long-ish command to import a database file - reading and unzipping it, and importing it by connecting to the database running in its container. The command would essentially be the same with slight changes based on that project - such as the database service name.
|
||||
|
||||
Now the command is the same for all projects, and I can automate it by writing a script that works on any project meaning I no longer need to write the long command at all.
|
Loading…
Add table
Add a link
Reference in a new issue