<p>Your scenario is a perfect use case for a <a href="https://en.wikipedia.org/wiki/Binary_repository_manager" rel="nofollow noreferrer">binary repository manager</a>. A BRM's primary feature is to act as a central storage system for your binaries, but there are many other features including:</p>

<ol>
<li>Versioning </li>
<li>Tagging</li>
<li>Permission management</li>
<li>Logging/auditing</li>
</ol>

<p>Using a BRM is more lightweight than a typical source code repository system such as Git or SVN. Those systems will have much more metadata than is necessary for binary files </p>

<p>I have personally used <a href="https://jfrog.com/artifactory/" rel="nofollow noreferrer">Artifactory</a> by JFrog, but I have also heard many good things about <a href="https://www.sonatype.com/nexus-repository-sonatype" rel="nofollow noreferrer">Nexus</a>. </p>

CC BY-SA 3.0
2018-02-07T14:57:59.367Z
2018-02-07T14:57:59.367Z
Preston Martin
<p>Another option if you are packaging your binaries (eg, as .deb or .rpm files) is to use a system like Foreman/Katello and the <a href="https://www.theforeman.org/plugins/foreman_ansible/2.x/index.html" rel="nofollow noreferrer">Anisble plugin.</a> Katello was originally developed as a plugin for Foreman, and then Merged into the Foreman project. It is backed by Red Hat and re-branded as <a href="https://access.redhat.com/products/red-hat-satellite" rel="nofollow noreferrer">Red Hat Satellite 6</a> if you wish to use their licensed and supported version. While the whole system collectively is for management of the Lifecycle of machines (both physical and virtual), it can also manage Docker containers too.</p>

<p>But for package management, Katello will allow you to import your packages after they are built. You are also able to create environments and content views that allow you to version and control which servers get what when. Essentially, this gives you all of the benefits of a <a href="https://en.wikipedia.org/wiki/Windows_Server_Update_Services" rel="nofollow noreferrer">WSUS server</a> for managing the release of your updates.</p>

<p>As an added bonus, Foreman can also create, destroy and build VMs for you with your cloud provider, or in your virtualization stack (if you do this in-house) using kickstart scripts.</p>

CC BY-SA 3.0
2018-02-08T16:45:24.520Z
2018-02-08T16:45:24.520Z
James Shewey
<p>I would like to improve the automation and performance when managing VMs using Ansible. One of my use cases is to install custom software on a variety of operating systems i.e Red-Hat, Ubuntu, Centos. This software is distributed using single-file installers.  For instance, installing a mySQL database on Red-Hat and Centos. </p>

<p>I recently learned about "repository managers" (or something similar). I don't know exactly where to look/learn more about what are the tools out there. I also don't know what the official terminology is. </p>

<p>This repository is ideally straightforward to use i.e, I just put a binary there, classify it with some tags[?] maybe like 64-bit, version 3.3, Centos. </p>

<p>Currently, I have this. But I don't really like hosting the binary on an NFS server</p>

<pre><code>name: Get mySQL binary
command: "find {{ nfs }} -name \"*mysql*\""
register: mySQL_location 

name: Install mySQL
command: "{{mySQL_location.stdout}} --option 1 --option 2
become: yes
</code></pre>

<p>A typical use case would look like this</p>

<ul>
<li>I want to install <code>Software A</code> on Centos</li>
<li>I use Ansible to get the appropriate OS specific version of <code>Software A</code> from a "central repository"</li>
<li>I use an Ansible module and specify version, OS, etc, and that downloads that binary (or binaries) to the VM. This should be fast since it will be over the local network, even for binaries of 100 MB+. Afterwards, Ansible installs it. </li>
<li>The Ansible role would be configurable to affect the installation settings, etc.  </li>
<li>Next, I want to reuse the same role to easily do the same for, let's say Red-Hat</li>
</ul>

<p>My goal is to have the Ansible playbooks be easily maintainable when a new version comes out, without, having to change anything in a playbook, just swap/add a new binary in the repository for a new version of <code>Software A</code></p>

<p>I understand that the YUM package manager does this in a way, however, I am wondering what other options (if any) are out there. </p>

CC BY-SA 3.0
2018-02-08T07:12:40.087Z
You should most definitely be building rpms/debs; keeping track of installed software is precisely what package managers do. And then as Preston says, you can just create a local repo and install packages out of that.
Xiong Chiamiov
<ansible>
Central repository hosting various binaries/applications for different platforms/architectures
keyboard
# Central repository hosting various binaries/applications for different platforms/architectures

(Asked by: username_0 on 2018-02-07)

I would like to improve the automation and performance when managing VMs using Ansible. One of my use cases is to install custom software on a variety of operating systems i.e Red-Hat, Ubuntu, Centos. This software is distributed using single-file installers.  For instance, installing a mySQL database on Red-Hat and Centos. 
I recently learned about "repository managers" (or something similar). I don't know exactly where to look/learn more about what are the tools out there. I also don't know what the official terminology is. 
This repository is ideally straightforward to use i.e, I just put a binary there, classify it with some tags[?] maybe like 64-bit, version 3.3, Centos. 
Currently, I have this. But I don't really like hosting the binary on an NFS server
name: Get mySQL binary
command: "find {{ nfs }} -name \"*mysql*\""
register: mySQL_location 

name: Install mySQL
command: "{{mySQL_location.stdout}} --option 1 --option 2
become: yes

A typical use case would look like this

I want to install Software A on Centos
I use Ansible to get the appropriate OS specific version of Software A from a "central repository"
I use an Ansible module and specify version, OS, etc, and that downloads that binary (or binaries) to the VM. This should be fast since it will be over the local network, even for binaries of 100 MB+. Afterwards, Ansible installs it. 
The Ansible role would be configurable to affect the installation settings, etc.  
Next, I want to reuse the same role to easily do the same for, let's say Red-Hat

My goal is to have the Ansible playbooks be easily maintainable when a new version comes out, without, having to change anything in a playbook, just swap/add a new binary in the repository for a new version of Software A
I understand that the YUM package manager does this in a way, however, I am wondering what other options (if any) are out there.

**Tags:** ansible

> **Comments:**
> **username_1**: You should most definitely be building rpms/debs; keeping track of installed software is precisely what package managers do. And then as Preston says, you can just create a local repo and install packages out of that.  

---

## 2 answers

### Answer by username_2 on 2018-02-07. Score: 2 | Accepted answer

Your scenario is a perfect use case for a [binary repository manager](https://en.wikipedia.org/wiki/Binary_repository_manager). A BRM's primary feature is to act as a central storage system for your binaries, but there are many other features including:

1. Versioning
2. Tagging
3. Permission management
4. Logging/auditing

Using a BRM is more lightweight than a typical source code repository system such as Git or SVN. Those systems will have much more metadata than is necessary for binary files

I have personally used [Artifactory](https://jfrog.com/artifactory/) by JFrog, but I have also heard many good things about [Nexus](https://www.sonatype.com/nexus-repository-sonatype).


---

### Answer by username_3 on 2018-02-08. Score: 0

Another option if you are packaging your binaries (eg, as .deb or .rpm files) is to use a system like Foreman/Katello and the [Anisble plugin.](https://www.theforeman.org/plugins/foreman_ansible/2.x/index.html) Katello was originally developed as a plugin for Foreman, and then Merged into the Foreman project. It is backed by Red Hat and re-branded as [Red Hat Satellite 6](https://access.redhat.com/products/red-hat-satellite) if you wish to use their licensed and supported version. While the whole system collectively is for management of the Lifecycle of machines (both physical and virtual), it can also manage Docker containers too.

But for package management, Katello will allow you to import your packages after they are built. You are also able to create environments and content views that allow you to version and control which servers get what when. Essentially, this gives you all of the benefits of a [WSUS server](https://en.wikipedia.org/wiki/Windows_Server_Update_Services) for managing the release of your updates.

As an added bonus, Foreman can also create, destroy and build VMs for you with your cloud provider, or in your virtualization stack (if you do this in-house) using kickstart scripts.


---

