verifa / ansible-katas Goto Github PK

Some playbooks miss an empty newline at the end of the file, making them unsightly to cat.
Some also have random trailing whitespace. Install the trailing whitespace VSCode plugin already, Laroy, I told you this before. 😮‍💨

Should we provide a full post exercises cleanup script? Trivial to implement, mainly a question of clutter and possible confusion in the repo, whether students would think you need to run it every time in between exercises, which is not true.

Once you spin up an exercise and you're inside your workspace container, it'd be nice to have the exercise README available in there as well for convenience.

Exercise setup scripts currently continue when an error occurs. (In my case lacking docker-compose.)
It'd be nice if the setup scripts stop when something's wrong. (Was it -e?)

YAML file extension consistency
.yaml or .yml, it doesn't matter, but pick one and stick to it. ;3

./utils/docker-compose.yml
./utils/docker-compose-multiple-hosts.yml
./4-roles/workspace/playbook-post-roles.yml
./4-roles/workspace/playbook-pre-roles.yml
./3-define-an-inventory-file/workspace/playbook.yaml
./2-install-cowsay-the-right-way/workspace/playbook.yaml
./1-my-first-playbook/workspace/playbook.yaml
./5-use-a-collection/workspace/playbook.yml

Assume cowsay is added to path

    - name: Say something
      shell: |
        cowsay hewwo
      register: out
    - debug: var=out.stdout_lines

Prevents playbook from blowing up: "stderr_lines": ["/bin/sh: 1: usr/games/cowsay: not found"]
Naturally, this applies to following katas as well.

EDIT: I noticed you can run into issues here when playbooks specify become: true -- but maybe we should look into why we're becoming root in all these exercises?

We currently have a technical training environment draft, and an initial design drafts (and in some cases full initial drafts) for what I would call the "introduction-to" part of the katas. Our design philosophy when making these was that

1. they should hopefully flow together nicely.
2. they should focus more on teaching the basics, perhaps at the expense of best practices if the best practices means a bit too much for the student at one time.

What we would love in terms of feedback here:

1. Test the technical training environment and give any feedback you can think of.
2. Do you think the step by step outline that exists in a exercise readme will be a good exercise once developed? if not, why?
3. Do you have any other ideas for exercises in the "introduction-to" part that you feel we have missed?

I noticed in playbook.yaml of first exercise we use apt instead of the generic package module: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/package_module.html

-ansible.builtin.apt
+ansible.builtin.package

This is a best practice so the play works on various operating systems, but of course this can quickly break and you have to start writing playbooks/roles/plays for different systems.

You can check if running_compose exists before tearing it down. Prevents some noise in the logs
utils/setup.sh

if [ -f running_compose ]; then
    docker-compose -f $(cat running_compose) -p ansible_katas down
fi