commit b320fb023519039562a22bdae5fc1df28e4b851c
parent f637dab7a5718d06db0ad7617ee94fce30fdd740
Author: pyratebeard <root@pyratebeard.net>
Date: Mon, 24 Jan 2022 23:48:59 +0000
make_it_happen
Diffstat:
1 file changed, 73 insertions(+), 34 deletions(-)
diff --git a/entry/make_it_happen.md b/entry/make_it_happen.md
@@ -1,81 +1,107 @@
-A while I ago I saw [this tweet](https://twitter.com/silascutler/status/1353385026994511872?s=19) by @silascutler who started using `make` to run `docker` commands.
+A while I ago I saw [this tweet](https://twitter.com/silascutler/status/1353385026994511872?s=19) by @silascutler who was using `make` to run `docker` commands.
-I was intrigued so I made a similar Makefile and tried using it when using Docker
+I was intrigued so I made a (very) similar Makefile and tried it when using Docker
```
override TAG = $(shell basename $$PWD)
VER := latest
IMAGE_ID = $(shell eval sudo docker images -qa ${TAG} | head -n 1)
-.PHONY: build test buildtest deploy
-
build:
- sudo docker build -t ${TAG}:${VER} .
+ sudo docker build -t ${TAG}:${VER} .
test:
- sudo docker run -d ${TAG}:${VER}
+ sudo docker run -d ${TAG}:${VER}
-buildtest:
- sudo docker build -t ${TAG}:${VER} .
- sudo docker run -d ${TAG}:${VER}
+buildtest: build test
deploy:
- @echo ${IMAGE_ID}
- sudo docker tag ${IMAGE_ID} pyratebeard/${TAG}:latest
- sudo docker push pyratebeard/${TAG}:${VER}
+ @echo ${IMAGE_ID}
+ sudo docker tag ${IMAGE_ID} pyratebeard/${TAG}:${VER}
+ sudo docker push pyratebeard/${TAG}:${VER}
+```
+
+This Makefile will use the directory name as the container tag if not specified. I did it that way so I can have one Makefile and symlink it into every project directory. The version is set to "latest" unless declared with the command
+```
+make build VER=1.0
+```
+
+The rest is pretty straight forward. A new container built from the current directory can be created and started if you incant
+```
+make build
+make test
+```
+
+Or you can perform both actions at the same time by incanting
+```
+make buildtest
```
-This Makefile will use the directory name as the container tag if not specified. I did it that way so I can have one Makefile and symlink it into every project directory. The version is set to "latest" unless otherwise.
+Pushing your image to your remote repo is as easy as
+```
+make deploy
+```
-The rest is pretty straight forward. If you incant `make build` then a container will be built from the current directory. If you incant `make test` then the container will be started up... for testing. You can probably guess what `make buildtest` does, and then `make deploy` will tag the latest build for the remote repo and push it up.
+## earth shaping in the cloud
-After using this for a while I thought it was handy enough and decided to try it with a few other tools.
+After using this for a while I thought it was working well so I decided to try it with a few other tools.
I wrote this Makefile for use with `terraform`
```
NAME := test
VARS := terraform
-.PHONY: plan planapply refresh destroy clean
-
init:
- terraform init
+ terraform init
plan: init
- terraform plan -var-file=${VARS}.tfvars -out ${NAME}.tfplan
+ terraform plan -var-file=${VARS}.tfvars -out ${NAME}.tfplan
apply:
- terraform apply -auto-approve -state-out=${NAME}.tfstate ${NAME}.tfplan
+ terraform apply -auto-approve -state-out=${NAME}.tfstate ${NAME}.tfplan
-planapply: init
- terraform plan -var-file=${VARS}.tfvars -out ${NAME}.tfplan
- terraform apply -auto-approve -state-out=${NAME}.tfstate ${NAME}.tfplan
+planapply: init plan apply
refresh:
- terraform refresh -state=${NAME}.tfstate
+ terraform refresh -state=${NAME}.tfstate
destroy: refresh
- terraform destroy -var-file=${VARS}.tfvars -state=${NAME}.tfstate
+ terraform destroy -var-file=${VARS}.tfvars -state=${NAME}.tfstate
clean: destroy
- rm -f ${NAME}.tf{plan,state{,.backup}}
+ rm -f ${NAME}.tf{plan,state{,.backup}}
```
+Using this Makefile I can init, plan, and apply a terraform state with one command. I can also manage multiple plans in the same directory.
+To create a "test" plan you incant
+```
+make plan
+```
+This will produce `test.tfplan`. You can then apply this plan by incanting
+```
+make apply
+```
+If you then wanted to use the same variables file (terraform.tfvars) to create another plan and apply it without losing `test.tfplan` you can incant
+```
+make planapply NAME=newtest
+```
+Coming back later you can destroy everything from `newtest.tfplan` if you incant
+```
+make destroy NAME=newtest
+```
+This will leave the `newplan.tfstate` file if you wanted to re-apply, or use `make clean` to delete everything.
-
+## as you drist
Then I got more adventurous and decided to write a Makefile for use with my `drist` modules (if you're not sure what `drist` is you can read [my post](https://log.pyratebeard.net/entry/20210305-the_usefulness_of_drist.html) about it)
```
-ERVER := ../inventory
+SERVER := inventory
FILESDIR = files
-.PHONY: patch pkgs create_user ssh_keys new_server sshd_config fail2ban dots
-
-# https://blog.melski.net/2010/11/30/makefile-hacks-print-the-value-of-any-variable/
env-%:
cd $* ; if [ ! -d ${FILESDIR} ] ; then mkdir ${FILESDIR} ; fi
cp env $*/${FILESDIR}
@@ -87,14 +113,14 @@ pkgs:
cd packages ; drist ${SERVER}
create_user: env-create_user
- cd create_user ; drist-root ${SERVER}
+ cd create_user ; drist ${SERVER}
ssh_keys:
cd ssh_keys ; drist ${SERVER}
new_server: env-ssh_keys
- cd create_user ; drist-root ${SERVER}
- cd ssh_keys ; drist-root ${SERVER}
+ cd create_user ; drist ${SERVER}
+ cd ssh_keys ; drist ${SERVER}
sshd_config: env-sshd_config
cd sshd_config ; drist ${SERVER}
@@ -109,3 +135,16 @@ secure: sshd_config fail2ban
commission: new_server patch pkgs secure dots
```
+
+There seems like a lot there but it should be fairly easy to figure out. I normally run this when I have built a new server and want to "commission" it with my settings
+```
+make commission SERVER=newhost
+```
+
+This will create a user and upload my ssh public keys, update the system (patch) and install a set of packages which I always want to have. It will then set a preconfigured sshd config file, install and configure fail2ban, and deploy my user configurations (dotfiles).
+
+## meet the maker
+
+Using `make` like this will probably make a lot of people shudder. I don't use it for everything but after trying the above I found writing a simple Makefile was slightly quicker than writing a wrapper script, and it's another way for me to confuse coworkers that like buttons over text.
+
+If you like this idea I would be interested to see what other tools people use Makefiles for. If you think the above can be improved let me know or raise a [Gitlab merge request](https://gitlab.com/pyratebeard/makefiles).
