51–60 of 90 posts
The biggest issue I've encountered on it is when you move out of AWS (and you can't apply EC2-based IAM) but still have S3-hosted artifacts. Specifically it cannot receive Vault secrets for the artifact credentials because the nomad templates get applied at a much later stage.
the qemu driver for nomad seems pretty bare bones compared to kubevirt https://www.nomadproject.io/docs/drivers/qemu https://kubevirt.io/user-guide/virtual_machines/disks_and_vo... Is terraform generally used to deploy workloads to nomad instead of writing tasks directly?
It can be, although it has some weird shortcomings. For example, if the job is already present in Nomad but not running ("dead"), I don't think you can use the terraform provider to start it again.
HashiCorp themselves suggest using terraform to provision the base nomad system (ACL, quotas, base system jobs), but perhaps not your actual applications:
> This can be used to initialize your cluster with system jobs, common services, and more. In day to day Nomad use it is common for developers to submit jobs to Nomad directly, such as for general app deployment. In addition to these apps, a Nomad cluster often runs core system services that are ideally setup during infrastructure creation. This resource is ideal for the latter type of job, but can be used to manage any job within Nomad.
https://registry.terraform.io/providers/hashicorp/nomad/late...
In my work helping companies with nomad, I've seen jobs run a few different ways:
* Write and submit HCL jobs directly to nomad
* Terraform templating and the nomad provider (as above)
* https://github.com/hashicorp/levant
* A DIY templating thing (e.g. python and jinja2 templates)
* A webapp that submits jobs as JSON directly to the nomad API, perhaps modifying it to match certain policies (kind of like k8s validating / mutating admission webhooks)
There's also a new thing similar to Helm: https://github.com/hashicorp/nomad-pack
As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engi…
I had a job interview where someone asked me what I would prefer Terraform or Cloudformation for AWS.
I said Cloudformation because it's managed by AWS who writes the actual software as well. And they kind of smugly said Terraform is better because it's cloud agnostic.
I was thinking...have you ever USED Terraform.
I've been using nomad for smaller setups in AWS and it's been great. The biggest issue I've encountered on it is when you move out of AWS (and you can't apply EC2-based IAM) but still have S3-hosted artifacts. Specifically it cannot receive Vault secrets for the artifact credentials because the nomad templates get applied at a much later stage.
https://github.com/hashicorp/nomad/issues/3854
I've used an nginx-based S3 proxy in the past to get around this. Not ideal but it works.
Earlier quoted context omitted.
Out of interest, do you find yourself writing actual software with CDK stacks integrated, or is it more accurate to say the CDK is just a stand-alone bit of code purely for deploying infrastructure? I'm definitely in the latter camp, which is something I find frustrating. I get that for a developer the syntax familiarity might make CDK easier, but for me as a non-developer the pain of groping around the terrible docu…
I strongly suspect that these CDKs are not very well designed. In particular, what I want is something that lets me generate YAML/etc in a type-safe fashion. That YAML is then the input for an engine which reconciles the desired state with the actual state (a la Terraform or cloudFormation). The idea is that the “real programming language” layer just allows us to DRY our YAML. For a use case like this, we don’t need…
As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engi…
As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engi…
>> but I just think a native solution of the platform is preferable over a 3rd party tool I had a job interview where someone asked me what I would prefer Terraform or Cloudformation for AWS. I said Cloudformation because it's managed by AWS who writes the actual software as well. And they kind of smugly said Terraform is better because it's cloud agnostic. I was thinking...have you ever USED Terraform.
Earlier quoted context omitted.
I agree with this. Terraform is definitely the least-bad tool, especially in that it integrates with so many more services than CloudFormation and has far fewer bizarre limitations than CloudFormation (e.g., you cannot pass objects in CF, and arrays can only be simulated as comma separated strings). Terraform isn’t great, but CF is awful, and even the AWS folks will point you at the CDK instead.
Agree CF is crap. Each clouds SDK in the language the team is most familiar with is by far the best option. State can be stored in git. Any version of my infrastructure is a git checkout away. I use Go, and the documentation for the AWS SDK includes copy-paste examples Try and checkout Terraform from 6 months ago and run it? Frequently I cannot even get someone’s tutorial example written a week prior to work without…
Creating resources with the SDK is easy—keeping them in the desired state is very hard.
Instead, we use a real language to generate a description of what we want (in YAML or HCL) and a reconciliation engine takes over from there.
As a DevOps guy, I'm not a huge fan of Terraform. Often I hear from enterprises that Terraform is cloud agnostic, but that's often very wrong. Terraform modules are still specific to the cloud platform and a rewrite is required to port an app running on AWS to GCP. If you use AWS, you're probably better off to use AWS Cloudformation and for GCP Google Cloud Deployment manager. A business reason is often that the engi…