Using curl bash to install local repo is probably not a great idea about deployment-automation HOT 3 CLOSED

What's the drawback? It's pretty common in large orgs, esp. in air gapped environments, to rely on a local repo...

from deployment-automation.

First, curl | sudo bash is a devops antipattern. It's not really considered idempotent and you can't rely upon it to converge to a known good state that's easily tested for. It's more of a hack to get developers up and running and not really meant to be used in automation.

I looked through the repo setup script that we provide and it really only does a handful of things that we could stuff into the ansible directly. It's not actually downloading and building a repo, it's only configuring the package handler to be aware of our repos.

For rpm-based installs it basically does:

1. setup the repo location: curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/config.rpm.txt?distro=centos&codename=Core&version=7&arch=x86_64' > redpanda-centos-el7-x86_64.repo
2. add our gpg key to trust the packages: rpm --import https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/gpg.988A7B0A4918BC85.key

It does something similar for deb-based ones.

from deployment-automation.

This is largely resolved. The sole exception is the download and dearmoring of a key

- name: Download and import Redpanda GPG Key
  shell: |
    curl -1sLf "{{ rp_key_deb_actual }}" | gpg --dearmor > "{{ rp_key_path_deb_actual }}"
  when: ansible_os_family == 'Debian'

I haven't found a good workaround to this method yet.

from deployment-automation.