Skip to content

June of 2023

Coding⚑

Languages⚑

asyncio⚑

aiohttp⚑

Configure Docker to host the application⚑

DevOps⚑

Infrastructure as Code⚑

Ansible Snippets⚑

  • New: Authorize an SSH key.

    - name: Authorize the sender ssh key
  authorized_key:
    user: syncoid
    state: present
    key: "{{ syncoid_receive_ssh_key }}"

  • New: Create a user.

    The following snippet creates a user with password login disabled.

    - name: Create the syncoid user
  ansible.builtin.user:
    name: syncoid
    state: present
    password: !
    shell: /usr/sbin/nologin

    If you don't set a password any user can do su your_user to set a random password use the next snippet:

    - name: Create the syncoid user
  ansible.builtin.user:
    name: syncoid
    state: present
    password: "{{ lookup('password', '/dev/null', length=50, encrypt='sha512_crypt') }}"
    shell: /bin/bash

    This won't pass the idempotence tests as it doesn't save the password anywhere (/dev/null) in the controler machine.

  • New: Create an ssh key.

    - name: Create .ssh directory
  become: true
  file:
    path: /root/.ssh
    state: directory
    mode: 700

- name: Create the SSH key to directory
  become: true
  openssh_keypair:
    path: /root/.ssh/id_ed25519
    type: ed25519
  register: ssh

- name: Show public key
  debug:
    var: ssh.public_key

  • New: Skip ansible-lint for some tasks.

    - name: Modify permissions
  command: >
    chmod -R g-w /home/user
  tags:
    - skip_ansible_lint
  sudo: yes

Chezmoi⚑

  • Correction: Give some tip to deal with big diffs.

    Sometimes the diff is too big and you need to work with it chuck by chunk. For each change you can either:

    • chezmoi add <target> if you want to keep the changes you've manually made to the files that match the <target>.
    • chezmoi apply <target> if you want to apply the changes that chezmoi proposes for the <target>.

    Here <target> is any directory or file listed in the diff.

  • New: Add systemd service for the actions runner.

    [Unit]
Description=Gitea Actions Runner
After=network.target

[Service]
WorkingDirectory=/var/gitea/gitea/act_runner/main
ExecStart=/var/gitea/gitea/act_runner/main/act_runner-main-linux-amd64 daemon

[Install]
WantedBy=default.target

  • New: Tweak the runner image.

    The gitea runner uses the node:16-bullseye image by default, in that image the setup-python action doesn't work. You can tweak the docker image that the runner runs by editing the .runner file that is in the directory where you registered the runner (probably close to the act_runner executable).

    If you open that up, you’ll see that there is a section called labels, and it (most likely) looks like this:

    "labels": [
  "ubuntu-latest:docker://node:16-bullseye",
  "ubuntu-22.04:docker://node:16-bullseye",
  "ubuntu-20.04:docker://node:16-bullseye",
  "ubuntu-18.04:docker://node:16-buster"
]

    You can specify any other docker image. Adding new labels doesn't work yet.

  • New: Introduce molecule.

    Molecule is a testing tool for ansible roles.

  • New: CI configuration.

    Since gitea supports github actions you can use the setup-molecule and setup-lint actions. For example:

    ---
name: Molecule

"on":
  pull_request:

env:
  PY_COLORS: "1"
  ANSIBLE_FORCE_COLOR: "1"
jobs:
  lint:
    name: Lint
    runs-on: ubuntu-latest
    steps:
      - name: Checkout the codebase
        uses: actions/checkout@v3

      - name: Setup Lint
        uses: bec-galaxy/setup-lint@{Version}

      - name: Run Lint tests
        run: ansible-lint

  molecule:
    name: Molecule
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - name: Checkout the codebase
        uses: actions/checkout@v3

      - name: Setup Molecule
        uses: bec-galaxy/setup-molecule@{Version}

      - name: Run Molecule tests
        run: molecule test

    That action installs the latest version of the packages, if you need to check a specific version of the packages you may want to create your own step or your own action.

  • New: Upgrade to v5.0.0.

    They've removed the lint command, the reason behind is that there are two different testing methods which are expected to be run in very different ways. Linting should be run per entire repository. Molecule executions are per scenario and one project can have even >100 scenarios. Running lint on each of them would not only slowdown but also increase the maintenance burden on linter configuration and the way is called.

    They recommend users to run ansible-lint using pre-commit with or without `tox. That gives much better control over how/when it is updated.

    You can see an example on how to do this in the CI configuration section.

Infrastructure Solutions⚑

AWS Snippets⚑

  • New: Get EC2 metadata from within the instance.

    The quickest way to fetch or retrieve EC2 instance metadata from within a running EC2 instance is to log in and run the command:

    Fetch metadata from IPv4:

    curl -s http://169.254.169.254/latest/dynamic/instance-identity/document

    You can also download the ec2-metadata tool to get the info:

    wget http://s3.amazonaws.com/ec2metadata/ec2-metadata

chmod +x ec2-metadata

./ec2-metadata --all

Storage⚑

Sanoid⚑

  • Correction: Use the recursive flag.

    recursive is not set by default, so the dataset's children won't be backed up unless you set this option.

     [main/backup]
   use_template = daily
   recursive = yes

Monitoring⚑

AlertManager⚑

  • New: Alertmanager routes.

    A route block defines a node in a routing tree and its children. Its optional configuration parameters are inherited from its parent node if not set.

    Every alert enters the routing tree at the configured top-level route, which must match all alerts (i.e. not have any configured matchers). It then traverses the child nodes. If continue is set to false, it stops after the first matching child. If continue is true on a matching node, the alert will continue matching against subsequent siblings. If an alert does not match any children of a node (no matching child nodes, or none exist), the alert is handled based on the configuration parameters of the current node.

    A basic configuration would be:

    route:
  group_by: [job, alertname, severity]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'email'
  routes:
    - match:
        alertname: Watchdog
      receiver: 'null'

Operating Systems⚑

Linux⚑

Gancio⚑

Other⚑

  • New: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress.

    This error can happen for few reasons, but it most commonly occurs when there is an interruption during the upgrade/install process as you already mentioned.

    To fix this one may need to, first rollback to another version, then reinstall or helm upgrade again.

    Try below command to list the available charts:

    helm ls --namespace <namespace>

    You may note that when running that command ,it may not show any columns with information. If that's the case try to check the history of the previous deployment

    helm history <release> --namespace <namespace>

    This provides with information mostly like the original installation was never completed successfully and is pending state something like STATUS: pending-upgrade state.

    To escape from this state, use the rollback command:

    helm rollback <release> <revision> --namespace <namespace>

    revision is optional, but you should try to provide it.

    You may then try to issue your original command again to upgrade or reinstall.