Skip to main content

Vendoring

Atmos natively supports "vendoring," a practice that involves replicating 3rd-party components, stacks, and artifacts within your own repository. This feature is particularly beneficial for managing dependencies in software like Terraform, which do not support pulling root modules remotely by configuration.

Vendoring standardizes dependency management, encourages enterprise component reuse, and ensures compliance standards adherence. Furthermore, it allows teams to customize and independently manage their vendored components according to their specific requirements.

Use-cases​

Use vendoring to maintain a local copy of external dependencies critical for managing your infrastructure. Organize the dependencies in the manner that best suits your project's structure. Even create multiple vendor manifests, for example, tailored to specific layers, products, or teams. Then easily update those dependencies by bumping the versions in the vendor manifest.

  • Managing Third-Party Dependencies: Use vendoring in Atmos to efficiently manage and version-control third-party Terraform components, modules or other infrastructure dependencies. This approach is crucial for teams relying on external libraries, root modules, and configurations from sources such as Git repositories. Vendoring these dependencies into your project repository ensures that every team member and CI/CD pipeline works with the same dependency versions, enhancing consistency and reliability across development, testing, and production environments.
  • Sharing Components Across an Enterprise: Utilize Atmos vendoring to access a centralized component library, promoting code reuse and efficiency across teams while enabling customization and independent version control post-vendoring. This approach enhances collaboration without sacrificing the flexibility for teams to tailor components to their specific needs or update them at their preferred pace.
  • Maintaining Immutable Artifacts for Compliance: Employ vendoring through Atmos to maintain local, immutable copies of remote dependencies, essential for meeting compliance and regulatory requirements. Keeping a local version-controlled artifact of dependencies ensures that your infrastructure complies with policies that mandate a record of all external components used within the system. This practice supports auditability and traceability, key aspects of maintaining a secure and compliant infrastructure.
  • Overcoming Tooling Limitations with Remote Dependencies: Utilize Atmos vendoring as a practical solution when your tooling lacks native support for managing remote dependencies. By copying these dependencies into your project repository, you can work around these limitations, ensuring that your infrastructure can still leverage essential external modules and configurations. This approach allows for greater flexibility in infrastructure management, adapting to tooling constraints while still benefiting from the broad ecosystem of available infrastructure modules and configurations.
  • Optimize Boilerplate Code Reusability with Vendoring Developers can utilize Atmos vendoring together with components to consolidate code by sourcing mixins (e.g. providers.tf, context.tf, etc) and boilerplate from centralized locations, streamlining development with DRY principles and immutable infrastructure.
Pro Tip! Use GitOps

Vendoring plays nicely with GitOps practices, especially when leveraging GitHub Actions. Use a workflow that automatically updates the vendor manifest and opens a pull request (PR) with all the changes. This allows you to inspect and precisely assess the impact of any upgrades before merging by reviewing the job summary of the PR.

Features​

With Atmos vendoring, you can copy components and other artifacts from the following sources:

  • Copy all files from an OCI Registry into a local folder
  • Copy all files from Git, Mercurial, Amazon S3, Google GCP into a local folder
  • Copy all files from an HTTP/HTTPS endpoint into a local folder
  • Copy a single file from an HTTP/HTTPS endpoint to a local file
  • Copy a local file into a local folder (keeping the same file name)
  • Copy a local file to a local file with a different file name
  • Copy a local folder (all files) into a local folder

Our implementation is primarily inspired by the excellent tool by VMware Tanzu, called vendir. While Atmos does not call vendir, it functions and supports a subset of the configuration that is very similar.

Use-cases​

Atmos vendoring streamlines component sharing and version control across an enterprise, enhancing efficiency and collaboration while offering the flexibility to customize and manage multiple versions of dependencies, ensuring best practices in DevOps environments.

  • Sharing Components Across an Enterprise: Utilize Atmos vendoring to access a centralized component library, promoting code reuse and efficiency across teams (or business units) while enabling customization and independent version control post-vendoring. This approach enhances collaboration without sacrificing the flexibility for teams to tailor components to their specific needs or update them at their preferred pace.
  • Managing Multiple Versions of Dependencies: Use Atmos vendoring to manage multiple versions of remote dependencies, effectively implementing version pinning through locally controlled artifacts. By configuring a stacks component directory (e.g., vpc/v1 or vpc/v2), vendoring provides maximum flexibility while still aligning with best practices in DevOps environments.
  • Reinforce Immutable Infrastructure: Employ Atmos vendoring to store immutable infrastructure artifacts, guaranteeing that once a committed, it remains unaltered throughout its lifecycle, ensuring stability and reliability in deployments.

Types of Vendoring​

Atmos supports two different ways of vendoring components:

  • Vendor Manifest Using vendor.yaml vendoring manifest file containing a list of all dependencies.
  • Component Manifest Using component.yaml manifest file inside of a component directory. See below.

The vendor.yaml vendoring manifest describes the vendoring config for all components, stacks and other artifacts for the entire infrastructure. The file is placed into the directory from which the atmos vendor pull command is executed. It's the recommended way to describe vendoring configurations.

tip

Refer to Atmos Vendoring for more details

The component.yaml vendoring manifest is used to vendor components from remote repositories. A component.yaml file placed into a component's directory is used to describe the vendoring config for one component only.