3 ms·

I'll definitely echo the sentiment about layers of incomprehensible crap in CM tools. I wrote my first set of Ansible scripts recently, and found myself deeply

by ajamesm 10y ago

I'll definitely echo the sentiment about layers of incomprehensible crap in CM tools. I wrote my first set of Ansible scripts recently, and found myself deeply pondering, "who on Earth thought YAML was the best option for a Turing-complete language?" CM tools should be saving me time. Writing under an isomorphism from BASH to YAML does not save me time.

Eridrus 10y ago
I feel like there are two alternatives to CM tools (of which I am only really familiar with Ansible): just running commands on machines, or shell scripts. At the very least shell scripts can be put into source control and run against a server. The main benefits I find over shell scripts are: 1) Ansible Galaxy sometimes already has playbooks to deploy the software I want to deploy. I try to contibute back since I really like the idea. 2) It can automate the AWS API for me; you could certainly write shell scripts to interact with the AWS CLI and have separate scripts for configuring AWS vs configuring images, etc. 3) It can capture how everything fits together in machine executable form, and it can provide structure to things such as files, templates, etc. 4) The fact that playbooks are idempotent means I test them as I make changes and don't just try to construct them from my bash history. 5) I can write python modules if I need something complicated; which is nice because I certainly don't want to be writing complicated bash scripts. I'll certainly concede that I recoil every time I have to do much logic in YAML, but it's not very common for what I've needed to do.
Terretta 10y ago
Don't program in Ansible, declare desired state. Use the Turing complete language under the hood, Python, to program. Use Ansible to compose: declare and configure your stack, invoking the things done by the real language.
- ajamesm 10y ago
  Okay, except I was already writing Python scripts to deploy, so now I'm where I started off except I have one additional engineer yelling at me for not doing things The Ansible Way. This is the exact problem the article was describing -- CM tools promise ease-of-use and simplicity, then that premise is inverted entirely when the developer is now doing additional work to satisfy the operations team's standards.
  - Terretta 10y ago
    Separating config from code or separating declarative environments from orchestration of components aren't to satisfy your ops team standards, they're things you probably want to do as a developer thinking of infra as code. Also, DevOps: It doesn't mean same person doing all things, but it does mean you don't think in us vs. them. Think about your app/service cradle to grave, do the right thing.
    - ajamesm 10y ago
      As a developer, I'm trying to meet deadlines with good-enough code. I'm not stupid and I certainly understand why someone would develop a general deployment strategy, and then each case can be described as a set of parameters. Again: the use case is clear to me. All of this makes sense in a world where the ops team is world-class and responsive, and you have the schedule and resources to delay deployment for another 2 weeks while you lovingly craft an Ansible module instead of hardcoding a BASH script. That does not describe business environments.

by ajamesm 10y ago

Eridrus 10y ago

I feel like there are two alternatives to CM tools (of which I am only really familiar with Ansible): just running commands on machines, or shell scripts. At the very least shell scripts can be put into source control and run against a server. The main benefits I find over shell scripts are: 1) Ansible Galaxy sometimes already has playbooks to deploy the software I want to deploy. I try to contibute back since I really like the idea. 2) It can automate the AWS API for me; you could certainly write shell scripts to interact with the AWS CLI and have separate scripts for configuring AWS vs configuring images, etc. 3) It can capture how everything fits together in machine executable form, and it can provide structure to things such as files, templates, etc. 4) The fact that playbooks are idempotent means I test them as I make changes and don't just try to construct them from my bash history. 5) I can write python modules if I need something complicated; which is nice because I certainly don't want to be writing complicated bash scripts. I'll certainly concede that I recoil every time I have to do much logic in YAML, but it's not very common for what I've needed to do.

Terretta 10y ago

Don't program in Ansible, declare desired state. Use the Turing complete language under the hood, Python, to program. Use Ansible to compose: declare and configure your stack, invoking the things done by the real language.

ajamesm 10y ago
Okay, except I was already writing Python scripts to deploy, so now I'm where I started off except I have one additional engineer yelling at me for not doing things The Ansible Way. This is the exact problem the article was describing -- CM tools promise ease-of-use and simplicity, then that premise is inverted entirely when the developer is now doing additional work to satisfy the operations team's standards.
- Terretta 10y ago
  Separating config from code or separating declarative environments from orchestration of components aren't to satisfy your ops team standards, they're things you probably want to do as a developer thinking of infra as code. Also, DevOps: It doesn't mean same person doing all things, but it does mean you don't think in us vs. them. Think about your app/service cradle to grave, do the right thing.
  - ajamesm 10y ago
    As a developer, I'm trying to meet deadlines with good-enough code. I'm not stupid and I certainly understand why someone would develop a general deployment strategy, and then each case can be described as a set of parameters. Again: the use case is clear to me. All of this makes sense in a world where the ops team is world-class and responsive, and you have the schedule and resources to delay deployment for another 2 weeks while you lovingly craft an Ansible module instead of hardcoding a BASH script. That does not describe business environments.