• 7 Posts
  • 17 Comments
Joined 1 year ago
cake
Cake day: July 25th, 2023

help-circle













  • z3r0@lemmy.ziptoDevOps@programming.devBest practice for Terraform state?
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    1 year ago

    If an entire region goes down, the Terraform status file stored there will not be useful at all because it only stores information about the resources you deployed in that particular region and your resources deployed there will also go down.

    Replicating the status file in another region will not be useful either because it will only contain information about the resources that are down in your region.

    The status file inventories all the resources you have deployed to your cloud provider. Basically Terraform uses it to know what resources are being managed by the current Terraform code and to be idempotent.

    If you want to set up another region for disaster recovery (Active-Passive) you can use the same Terraform code, but use a different configuration (meaning different tfvars files) to deploy the resources to a different region (not necessarily to another account). Just make sure that all your data is replicated into the passive region.




  • I totally agree that. But I suppose that with this rebranding they are looking for moving away the original project as much as possible.

    I’m not sure if this movement has a lot of sense right now because by when the project had finally been released it will still being a fork of the original Terraform, but they may change this in a near future.








  • z3r0@lemmy.ziptoDevOps@programming.devWhat is GitOps?
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    This is a very interesting approach that we are starting to fully adopt in our organization for our Kubernetes deployments.

    We switched from Helm (using Helmfile) to ArgoCD to deploy applications into our clusters.

    The main challenge here is how to design a good repository structure to organize the ArgoCD applications because there is nothing said about which is the best approach that must be followed.

    Finally we decided to use ApplicationSets to deploy umbrella charts that are defined in the repo. The Chart.yaml of our umbrellas contain the charts that we really want to deploy as if they were dependencies (such as as Ingress Nginx) and their chart versions and the values.yaml contains the values for a particular cluster.

    Another interesting issue is how we manage secrets. We were using sops along with helm secrets plugin to automatically decrypt secrets when running helmfile apply. Fortunatelly the helm secrets plugin can be installed as an addon on ArgoCD via an initScript or developing a custom ArgoCD image.