I thought Docker builds are not generally repeatable, since they often `apt-get update && apt-get install`, which depends on the current state of external package management?
They are definitely not reproducible in the sense of building bit-for-bit identical containers, unless you use Bazel.
That being said, I've found Dockerfiles to be a much more reliable build process than most others (recently struggled to get through LogDevice's cmake-based build.. ugh).
You’re correct, but how reproducible you’re builds end up being depends on how you use it, and how reproducible you need them to be depends on your use case. Maybe a particular use case wouldn’t fit in very well, maybe it would be better served by using something like packer, maybe your dependency management requirements mean you should use something like artifactory. No technology is going to be suitable for everybody’s needs, but Docker provides enough value to enough people that it’s found a place in the market. If it Docker dies, I’d imagine it would be because it was replaced by something better, not because people suddenly realized that they weren’t getting any value out of it.
Your favorite tool that produces json should be able to work. I'd probably use jsonnet, which has a multi-file mode so that one template file can render into many json files.
Question that's been bugging me and I haven't quite wrapped my head around --
For light usage, I find managing Terraform's state to be a significant hurdle. You basically have no choice but to set up secure remote storage unless you want to check passwords into source control. In contrast `kubectl apply` is so easy to use since it's stateless. It just creates or updates any resources provided, and it even supports --prune if you want the set of configuration to be treated as comprehensive.
It seems like the main things that Terraform adds:
1. The ability to work with providers that require you to store their generated IDs to reference later. With kubernetes, the kind and name of the resource is enough to identify it; it does get assigned a UID, but you don't have to include that in the configuration since keys that are excluded are left as-is.
2. The ability to work with multiple different providers. I'm not sure how often you do have a single terraform project(is that the term?) with more than one provider, but I guess using the same set of tools, even if the configuration is provider-dependent, is nice.
Is that accurate? Does Terraform offer any other advantages?
If you were building a configuration mechanism for your system from scratch to allow your users to configure it as code, would you make .a Terraform provider over a command line tool that can apply [--prune] that same configuration?
Terraform shine when you combine multiple providers, kubectl manages Kube but Terraform helps you integrate K8s with the rest of your infrastructure (monitoring, Sentry,GitHub and GitLab, etc.)
> I find managing Terraform's state to be a significant hurdle
Have a look at https://app.terraform.io/signup/account, it's the free version of Terraform Enterprise and it makes managing your state very easy.
>If you were building a configuration mechanism for your system from scratch to allow your users to configure it as code, would you make .a Terraform provider over a command line tool that can apply [--prune] that same configuration?
I would make a Terraform provider, you get plans, modules, the possibility to integrate with other providers easily and creating a new Terraform provider is actually very easy!
To elaborate: The spirit of a one-pager isn't to cram everything onto "one page", but rather to have a "single document" that contains all the context/content you need instead of having hyperlinks to large swaths of other documents (doing a depth-first search in documentation at Google can be a huge time-sink).
Source: Another Googler that wastes time on memegen
According to the announcement [1], gorename is able to rename just about any identifier (function, method, exported variable, local variable) throughout your entire GOPATH, not just a file. I tried it out and it seemed to work fine. Additionally, it seems to detect at least some cases where the rename would cause the resulting code to not work, although you can -force it to apply the changes anyway.
I happen to agree that Go could use more refactoring tools, but I think it's in good shape considering how young it is.
That's a graph from webmaster tools. It may be that the Google Bot is hitting some pathological case with the Django (e.g. server-side sessions) or Disqus. I don't think he ever tested the latency directly.
They are definitely not reproducible in the sense of building bit-for-bit identical containers, unless you use Bazel.
That being said, I've found Dockerfiles to be a much more reliable build process than most others (recently struggled to get through LogDevice's cmake-based build.. ugh).