daily-email: add 2023-04-18
This commit is contained in:
parent
72c73c0cf1
commit
168f51105d
23
src/content/daily-email/2023-04-18.md
Normal file
23
src/content/daily-email/2023-04-18.md
Normal file
|
@ -0,0 +1,23 @@
|
||||||
|
---
|
||||||
|
title: >
|
||||||
|
Consistency is key
|
||||||
|
pubDate: 2023-04-18
|
||||||
|
permalink: >
|
||||||
|
archive/2023/04/18/consistency-is-key
|
||||||
|
tags:
|
||||||
|
- automation
|
||||||
|
- devops
|
||||||
|
- docker
|
||||||
|
---
|
||||||
|
|
||||||
|
A side effect of [using a tool to generate build configuration files](https://www.oliverdavies.uk/archive/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…
Reference in a new issue