Automated test jobs at $my_company curl this URL as part of their setup. These jobs now fail because of this external dependency. There's definitely a lesson here.
However I wonder how a soon-to-expire certificate goes unnoticed nowadays, with all the automation available.
Over the past couple years, I have set up different ways of managing secrets in the cloud. I really like Berglas’ and BankVaults’ model of having a custom entrypoint that fetches secrets and provides them to the application via its environment variables. The approach has limits but I always found its simplicity elegant.
Berglas works for GCP and BankVaults works for Vault, but there was no equivalent for AWS and Azure. So I wrote whisper. The goal is for it to support many secret storage providers, even fetching from multiple at once.
I work with Terraform a lot and sometimes with large legacy codebases that are hard to navigate and improve. In those cases, I want to refactor so that the code is actually structured like the infrastructure it defines, but Terraform makes that difficult. Its inherent statefulness makes moving a resource from one module to another quite tedious. Moving a lot of resources around is a lot of toil.
A few months back a colleague of mine had an idea: what if we could automatically move resources based on Terraform's plan? They implemented a quick and dirty tool that did just that for a specific project they were working on. And it worked! They saved a lot of time, reduced potential for human error and avoided a few headaches.
Another colleague and I decided to redesign the tool from scratch to make it more generic and rigorous (the original version sometimes made guesses). We have been using this new version where I work and it works well! I convinced my boss to make it open source, because I believe it can help many Terraform users who need to refactor their codebase.
Tfautomv's internal logic is provider-agnostic. Its only source of information is Terraform's plan. If Terraform plans to destroy a resource and create another with the same type and attributes, tfautomv considers this a match. If two resources match each other and only each other, then it writes the corresponding "moved" block. That is pretty much it.
I hope you will try it out. If you find any issues or have any ideas for additional features, let me know! All feedback is welcome :)
Ansible connects to remote servers to configure them, while Terraform calls cloud provider API’s to provision resources.
For example, you can use Terraform to provision virtual machines, database instances, or Kubernetes clusters on AWS. Terraform does this via the AWS API.
In my opinion, Terraform is better for provisioning because of the way it manages its own state. Terraform remembers what resources it created the last time it ran, and can edit or delete them according to any change in your Terraform code.
I like Ansible, but not for managing cloud resources. Ansible has no memory. For example, if I ran a playbook that installs MySQL, Ansible has no built-in way to undo this change and bring me back to my previous state.
The blog post links to the Semantic Versioning spec, specifically item 9.
> A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
Item 10 explains how + can be used to add a build tag.
> Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
Instead of using v1.2.3bigco1 or v1.2.3+bigco1, we should use v1.2.3-bigco1. If we need to add a build tag we can use v1.2.3-bigco1+001.
I was at DockerCon EU today when Matt Butcher announced this. I wondered how CNAB would relate to existing cloud native package managers like Helm, especially since a big part of Helm comes from Matt himself.
He told me that he and his team saw the need for something like CNAB after finishing their work on Helm 2, but that they would keep working on Helm 3. He also explained that Helm could be used to install some or all components of an application bundled in CNAB format, which makes sense.
However I wonder how a soon-to-expire certificate goes unnoticed nowadays, with all the automation available.