<p>Problems with golden images are that you have to store a full system image with overhead of data which is not build-specific, and using conventions for configuration to make deploy process the same for all versions.</p>

<p>TL;DR: Infrastructure as a Code, version-specific storage for data outside the app package.</p>

<p>The problem is easily solved by storing config files and templates, data and installation scripts (including ansible playbooks to manage) inside both code and packages/images, so install and initial configuration would always be version-specific (switching to the same commit you are deploying to have configs you need). This could be done with VCS and current package management software (deb, msi, PKG etc. and scripts for unattended deploy and installation) with ease. To avoid using different images of OS and other environment, storing and using a single <em>golden image</em> for all builds is a standard practice: it provides consistency and you can automate CI/CD pipeline for image update process.</p>

<p>If some data is stored outside (<em>i.e. a lot of current Windows apps outside of Store are installed by running a downloader, then installing app</em>) and you have to keep large number of them (no specific branches only like stable-beta-alpha), then storage should be versioned too (i.e. using version-specific hashes as names) and links in install scripts or artifacts would point to the one version they need. But you also have to keep the register of pairs <code>build:data version</code>, so when there's no need to use specific version, deletion of related data could be performed within the same remove process. Also, you have to decide whether you want to store complete images or use some differential systems (incremental or differential snapshots of files/filesystems), latter is much more complex and hard to manage so it's not used widely AFAIK (with an exception for some DBs, i.e. Facebook stores MySQLs snapshots and binary transaction logs so they could deploy or restore exact state up to certain transaction id).</p>

CC BY-SA 3.0
2017-08-30T19:00:39.230Z
2017-08-31T07:27:01.493Z
2017-08-31T07:27:01.493Z
chupasaurus
<p>Have created a number of images via packer and soon coming to the conclusion that binaries/images soon rack up in qty and need to find away to store config data. </p>

<p>We are going to use ansible to hold config data for apps and was wondering about how people manage versions of binaries, versions of images, ingress egress data etc etc. I wondered if anyone knew of either a regularly used/industry approach to managing app data, versioning, config data etc.  My default thought was a scheema to use in ansible, or perhaps a tool that can manage this data.</p>

<p>A combo of packer images, binaries and other images I am beginning to think that these files could increase in numbers v v quickly. How do people manage this info??</p>

<ansible><build-pipeline><packer>
Storing Meta Data for Apps/tools
Nick Gleed
# Storing Meta Data for Apps/tools

(Asked by: username_0 on 2017-08-30)

Have created a number of images via packer and soon coming to the conclusion that binaries/images soon rack up in qty and need to find away to store config data.

We are going to use ansible to hold config data for apps and was wondering about how people manage versions of binaries, versions of images, ingress egress data etc etc. I wondered if anyone knew of either a regularly used/industry approach to managing app data, versioning, config data etc. My default thought was a scheema to use in ansible, or perhaps a tool that can manage this data.

A combo of packer images, binaries and other images I am beginning to think that these files could increase in numbers v v quickly. How do people manage this info??

**Tags:** ansible, build-pipeline, packer


---

## 1 answers

### Answer by username_1 on 2017-08-30. Score: 3 | Accepted answer

Problems with golden images are that you have to store a full system image with overhead of data which is not build-specific, and using conventions for configuration to make deploy process the same for all versions.

TL;DR: Infrastructure as a Code, version-specific storage for data outside the app package.

The problem is easily solved by storing config files and templates, data and installation scripts (including ansible playbooks to manage) inside both code and packages/images, so install and initial configuration would always be version-specific (switching to the same commit you are deploying to have configs you need). This could be done with VCS and current package management software (deb, msi, PKG etc. and scripts for unattended deploy and installation) with ease. To avoid using different images of OS and other environment, storing and using a single *golden image* for all builds is a standard practice: it provides consistency and you can automate CI/CD pipeline for image update process.

If some data is stored outside (*i.e. a lot of current Windows apps outside of Store are installed by running a downloader, then installing app*) and you have to keep large number of them (no specific branches only like stable-beta-alpha), then storage should be versioned too (i.e. using version-specific hashes as names) and links in install scripts or artifacts would point to the one version they need. But you also have to keep the register of pairs `build:data version`, so when there's no need to use specific version, deletion of related data could be performed within the same remove process. Also, you have to decide whether you want to store complete images or use some differential systems (incremental or differential snapshots of files/filesystems), latter is much more complex and hard to manage so it's not used widely AFAIK (with an exception for some DBs, i.e. Facebook stores MySQLs snapshots and binary transaction logs so they could deploy or restore exact state up to certain transaction id).


---

