[HN Gopher] Show HN: Etcha - Infinite scale, serverless config m...
___________________________________________________________________
Show HN: Etcha - Infinite scale, serverless config management
While developing a SaaS, we needed a way to distribute
configurations across a wide array machines in a distributed
manner. We built Etcha as a way to build and run servers and
applications using familiar Jsonnet and GitOps workflows--lint,
test, build, and release.
Author : candiddevmike
Score : 35 points
Date : 2023-11-18 15:39 UTC (7 hours ago)
(HTM) web link (etcha.dev)
(TXT) w3m dump (etcha.dev)
| cedws wrote:
| I've desperately wanted a modern config management tool for ages.
| This looks nice, although I'd need to actually use it to be able
| to tell if would work for me. I've worked with both Ansible and
| Puppet and prefer Puppet's architecture, but it is an absolute
| beast of a tool.
|
| Unfortunately, I think the production licensing here will limit
| the success. I can't see companies forking out $1,000 a year for
| an immature tool with no ecosystem when they could just use
| Ansible/Puppet/Salt. Not necessarily even because of the cost,
| it's just a lot of extra bureaucracy to get products approved in
| some places.
| candiddevmike wrote:
| I have a few customers, the $1,000 subscription isn't a deal
| breaker at all. It's typically easy to get small expenses like
| that approved/whip out the credit card for most businesses.
|
| Additionally, you can use the software without the subscription
| for your personal needs or in a non-production/evaluation
| phase.
|
| In the next couple of weeks we'll release EtchaOS, an immutable
| "meta Linux distro" that bundles Etcha, systemd, and
| containerd/docker on different variants like Debian, Alma,
| Fedora and architectures like amd64 and aarch64.
| cedws wrote:
| Yes, I don't doubt you'll have customers. From the docs, I
| just don't see a compelling advantage Etcha has over existing
| tools that justifies the cost.
|
| Did you consider having an open beta? It might allow the
| ecosystem to develop while still enabling you to charge for
| the product later down the line.
|
| At my last job at a bank you most likely know of, getting any
| kind of product is a multi-month painful bureaucratic
| process. So engineers tend to live off the land with the
| stuff they can get for free, despite funds not being an
| issue.
| candiddevmike wrote:
| > Did you consider having an open beta? It might allow the
| ecosystem to develop while still enabling you to charge for
| the product later down the line.
|
| I don't think being free for personal/non production limits
| the ecosystem at all. Additionally, I don't appreciate rug
| pulls from changing free to non-free down the road, and I
| doubt my customers would.
|
| The pricing is what it is: ensure Etcha is sustainable and
| supported. Think of it as a forced OSS donation if you
| want. There's way more than $1,000 worth of value here.
| cedws wrote:
| >I don't think being free for personal/non production
| limits the ecosystem at all
|
| There are two aspects. The first one being that charging
| a nonzero amount decreases adoption, so fewer companies
| will publish modules and tools around it. The other is
| that people will generally not want to send pull requests
| adding features to something they have no stake in. If we
| take HashiCorp Packer or Ansible as an example, they have
| flourished as engineers send PRs extending the tools for
| their own purposes.
|
| Another thought that comes to mind is: what if your
| company disappears one day? Can you make some assurances
| that the source will be relicensed to allow users to
| maintain it?
|
| I wish your product great success. If it feels nice I may
| even end up getting a license in a future job myself. But
| I have stated my concern of missing out on all that the
| Ansible/Puppet community already provides.
| kodama-lens wrote:
| I get some "managed ansible executor" vibes from this. And having
| a hard time differentiating it form the ansible approach. What
| advantage does this custum format vs industry standard tools?
|
| Also not entirely sure how state/sync loop is archived from what
| I've read in the docs. Do I have to change my app to pull config?
| candiddevmike wrote:
| There are a few advantages with the tool:
|
| - It's Jsonnet instead of YAML/HCL. That means real functions,
| imports, and data structures.
|
| - It has built in testing and linting functionality
|
| - While push mode functions similar to Ansible, pull mode can
| scale infinitely as it's just clients pulling a text file.
| Ansible and friends have a lot of scaling issues with larger
| clients.
|
| - All of the rendering happens on the client, no need to bundle
| secrets.
|
| The state/sync loop is achieved by running Etcha as a service
| or container in pull or push mode. Etcha will periodically pull
| down new JWTs (or receive pushed) and diff them, run the
| changes or remove the commands that aren't present.
| evulhotdog wrote:
| Check out ansible-pull, which is installed by default with
| Ansible.
| candiddevmike wrote:
| Ansible pull is definitely an option, but it's not how most
| folks use Ansible in my experience (preferring Tower or
| adhoc run books), namely because it's harder to centrally
| manage and configure. Etcha creates release artifacts
| instead of pull down a git repo, and allows you to monitor
| your deployment using metrics services like Prometheus.
| Additionally, there is a complete webhook framework for
| triggering runs.
| nurple wrote:
| It's nice that you've decided to throw off the golden veil of
| "declarative" that so many of the tools try to sell themselves
| as, while in practice the user still ends up attempting to write
| imperative logic while harangued by the declarative
| representation.
|
| Couple things I personally take issue with:
|
| String-embedding of code and templates is just straight up a
| nonstarter for me. I've seen enough dev/ops people struggle with
| tools like nomad and helm to know any sufficiently complex setup
| will inevitably become huge, opaque, usability mess.
|
| Finally, I just don't believe a "mutate the bag of state"
| strategy is the future of config management or DevOps tech. It's
| shown itself time and time again to be the weakest part of
| systems like salt, ansible, and puppet. I can't count the number
| of hours of my life that have been wasted writing code that
| attempted to, poorly I might add, perpetuate the lie of
| determinism this tooling tries to sell on top of the mutable bag
| of state that is an OS.
| candiddevmike wrote:
| > String-embedding of code and templates is just straight up a
| nonstarter for me
|
| Can you expand on this?
|
| > Finally, I just don't believe a "mutate the bag of state"
| strategy is the future of config management or DevOps tech.
|
| Unfortunately that is how operating systems work (today). Even
| Nix struggles with state (though that's typically a bug).
| Properly controlling/preventing side effects with configuration
| management would require a new OS paradigm IMO.
|
| > I can't count the number of hours of my life that have been
| wasted writing code that attempted to, poorly I might add,
| perpetuate the lie of determinism
|
| One nice thing of Etcha is it makes testing your stuff really
| simple. Testing is baked into the tool, and you don't really
| have to write separate tests, the test is if your check
| passes/fails correctly after a command is changed/removed.
| Checkout the docs on it here for more info, it really helps
| with validation: https://etcha.dev/docs/guides/testing-patterns
| nurple wrote:
| Re embedding, just to take one snippet from an example on
| your site: { always: true,
| change: 'echo %s > /work/helloworld' % n.getEnv('HOSTNAME'),
| id: 'write a file', onChange: [ 'read
| file', ], }
|
| This may be quite clear in its simplicity, and particularly
| to those familiar with etcha/jsonnet. However, what
| invariably happens is that you start seeing things like vars
| embedded in templates, embedded in the config mgmt
| implementation language, embedded in strings. The source of
| the values becomes incredibly difficult to reason about and
| to make changes against; does the value come from the target
| host's env, from the runner's env, from the packaging step's
| env, from a network request made by one of these stages (eg
| to a secret server), etc.
|
| Take a look at an example of what, IMO, is an absolutely
| horrid helm chart that Gitlab ships for installing their
| CI/CD runner: https://gitlab.com/gitlab-org/charts/gitlab-
| runner/-/blob/ma...
|
| Bash code, in yaml, in golang template. Besides even the most
| advanced IDEs failing to grok such a freak of technical
| nature, there's no way I would believe any dev that told me
| they understand what the state of their system will be given
| some input to this morass.
|
| In a recent position I was asked to try and make an existing
| nomad installation viable in a pretty standard corporate
| environment (not some special operational space e.g.
| cloudflare), and it was even worse; some configuration
| expansion was 5 layers deep, with 3 different templating
| engines, once consul templates were involved in generating an
| app's config, and the nomad config being env-generalized
| through generation by a higher-level helm-like tooling.
|
| Re state bag:
|
| I'm glad you mentioned nix, as I think it, and to a looser
| extent containers, really approach the issue in the only
| humanly-tenable fashion (again IMO): starting mutation from a
| known state. In a lot of cases that state is "nothing" as
| it's the simplest known state not only to position the
| beginning of some configuration flow at, but also the most
| straight-forward from which to deterministically derive a
| desired end state from.
|
| I definitely applaud having tests as a core component of your
| system, the problem is that you can not derive determinism
| from nondeterminism even with the best tests.
|
| Because you are operating over a nondeterministic bag of
| state, you can never guarantee that your tests provide a
| representation of a transfrom from any potential state to the
| desired end state, only for some particular input state (or
| set) which may or may not representative of what is found on
| the actual targets.
| linsomniac wrote:
| Your comment really resonates with me, because I'm
| experimenting with a project to do "ansible, but with Python
| syntax" [1]. It has some declarative abilities, but also full
| imperative abilities, and does away with "coding in YAML", so I
| get full LSP abilities.
|
| I've considered the question: What is the difference between
| declaratively providing an Apache config file, and just copying
| that file over unconditionally? The big benefits I've come up
| with are: - Detecting the change so I can
| trigger an Apache restart only when the file has changed.
| - Ability to do "--check" and "--diff" to tell me what will
| change during a dry run.
|
| With the downside that the "tasks" become more complicated to
| build.
|
| I had previously built a version of my tool that was just a
| simpler, local ansible-like tool, with a YAML syntax and
| realized: I really hate coding Ansible playbooks in YAML. So I
| started imagining what it might look like if it was in code. I
| picked Python syntax because I really didn't want to write a
| parser for a DSL and wanted to see if I could get close enough
| without it.
|
| [1] https://github.com/linsomniac/uplaybook
| krab wrote:
| That looks great!
|
| I'm trying to do a similar thing but I'd like to be
| compatible with the existing Ansible tasks. Still trying to
| figure out the API, especially for cases like calling a
| playbook from playbook with some parameters.
| linsomniac wrote:
| I am looking at adding the ability to call Ansible tasks
| (community.apt, for example) from uPlaybook, but that would
| not involve calling YAML playbooks I'm not thinking... But
| maybe that would be possible.
|
| I did try some other YAML control structures in the
| original version of uPlaybook, what I'm calling uPlaybook1
| [1] now, which I think has some more natural control
| structures than Ansible. If you are doing something
| similar, may be worth looking at what I came up with:
|
| - I ended up using "block:" as a way of grouping tasks, and
| you could add conditionals or loops on those:
| block: tasks: - copy:
| [args here] - command: [more args
| here] loop: - vars:
| basename: XXX - vars: basename
| YYY
|
| - Conditionals were also blocks and could be nested within
| loops: - if: condition: "x < 1"
| tasks: - copy: [args here]
| - elif: condition: "x >= 1 and x < 10"
| tasks: [tasks here] - else:
| tasks: [more tasks here]
|
| [1] https://github.com/linsomniac/uplaybook1
| CaveTech wrote:
| This is essentially Chef
| nurple wrote:
| Love that you're playing in the space! The more people that
| experiment with approaches, the more we'll see what does and
| doesn't work.
|
| Couldn't agree more with how painful "coding" in ansible is,
| my SOP with it is usually just to write a python module to
| model the flow I'm interested in the moment I find myself
| trying to implement logic at the yaml layer. The module API
| isn't horrible, I prefer it quite a bit over puppet's
| extensibility constructs.
|
| However, the nondeterministic bag-of-state issue will still
| be impossible to overcome with this strategy. Not to say that
| making a better ansible isn't valuable for configuration of
| legacy workloads in legacy runtime environments, only that
| it's a space that I'm personally putting a lot of energy into
| never interacting with again if I can help it.
| linsomniac wrote:
| I don't understand what you mean by "nondeterministic bag-
| of-state" I guess...
| n3storm wrote:
| Why not saltstack?
| linsomniac wrote:
| At the time I selected Ansible, Saltstack had just had a
| fairly serious "we invented our own crypto" issue, but also
| Ansible's agentless approach was nice for my environment,
| though saltstack did have some great demos of what you
| could do with their approach, and, I had friends who were
| working on Ansible, which seemed like it was worth
| something... I'll take a look to see if Saltstack is in the
| same space as uPlaybook.
| siliconc0w wrote:
| I proposed something similar at $work for edge environments where
| a full k8s CP doesn't make sense though I kept it pull only by
| polling S3 for work and pushing responses to an append only log.
| This uses a declarative k8s syntax so it theoretically allows
| workloads to be managed either way.
|
| Didn't really get traction, glad to see something like it
| realized even if it isn't the licensing model I'd pick
| Alifatisk wrote:
| Infinite scale huh?
___________________________________________________________________
(page generated 2023-11-18 23:01 UTC)