6 ms·

Personally I'd much rather see a GUI that can help string together snippets of Terraform/CFN and Ansible/Chef/Puppet/Salt/whathaveyou. A visual IDE for infrastr

by maxaf 9y ago

Personally I'd much rather see a GUI that can help string together snippets of Terraform/CFN and Ansible/Chef/Puppet/Salt/whathaveyou. A visual IDE for infrastructure automation, if you will.

dalore 9y ago
Doesn't Ansible Tower do this (At least for ansible)?
- maxaf 9y ago
  I haven't used it personally, but judging by the marketing video Tower is mostly an enterprise dashboard with some self-serve features that allow invocation of Ansible playbooks (or perhaps some larger unit of automation - I've no idea if they made something up just for Tower); but the playbooks would still need to be hand-coded elsewhere.
  - dalore 9y ago
    Ahh I thought you meant you got some playbooks/roles/modules written but you have a gui to say which are run where. More of a higher level. But I think I see what you mean and I like the idea. A low level GUI that lets you look up specific tasks in ansible and have it create the playbook for you at the end. That would be pretty cool and not that hard to write actually.
    - epicide 9y ago
      Combined with Ansible Galaxy, I think you get pretty close.
ohples 9y ago
Yeah I also wish there was some good Config Management IDEs. I think someone like InteliJ might be able to make a decent one.
- snuxoll 9y ago
  If you're doing Puppet then the plugin for IntelliJ works pretty well with Puppet code, including reference checks and all the good stuff you'd expect from a half-decent IDE. Can't say anything about Chef or Salt, but with Ansible you get basically shit for help since the IDE just sees a YAML file and nothing more. This is partially the fault of Ansible though, to be honest, modules being standalone scripts that is cool - but they provide no standardized way to inspect their parameters and outputs beyond documentation.
  - kilburn 9y ago
    Ansible's modules documentation is auto-generated from the code. Hence, there is a standardized (across all ansible's modules) way to extract their parameters/outputs. See https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/files/iso_extract.py https://github.com/ansible/ansible/blob/devel/lib/ansible/mo... for example: DOCUMENTATION is a yaml snippet that follows their documentation schema to tell you about all the module's input parameters. EXAMPLES gives you some usage examples. RETURN documents the outputs. A proper IDE plugin could parse those snippets for each module and do some pretty nice autocompletion/inline documentation for you...
- ryanschneider 9y ago
  The terraform plugin for jetbrains products works really well. It auto completes all the resource types and knows what keys are valid under each one, so will suggest keys and highlight a resource as invalid if it’s missing a required key. I can’t imagine coding terraform plans without it.
sciurus 9y ago
So the idea is that you would choose your changes in the GUI, but instead of actually changing the target, it spits out the required code to do it for you in a repeatable way? I would definitely find that useful for Terraform and Cloudformation. Searching for it, I see that AWS has a tool targeted at that: Cloudformation Designer. https://aws.amazon.com/blogs/aws/new-aws-cloudformation-designer-support-for-more-services/ https://aws.amazon.com/blogs/aws/new-aws-cloudformation-desi... https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
- jamiesonbecker 9y ago
  Example Cloudformation Designer stack diagram (click View In Designer or scroll down for a screenshot): https://userify.com/docs/enterprise/cloudformation/ https://userify.com/docs/enterprise/cloudformation/ If you have an AWS account, you can actually modify/fork the template on the fly by clicking on one of the objects in the diagram and editing its properties (which edits the YAML CloudFormation template in the background).
- 0xbadcafebee 9y ago
  A better idea would be to spit out a spec that tools could use to perform the thing, and get tools to follow the spec. Unfortunately, even though most tools do virtually the exact same thing, they all use their own incompatible ways to describe it in a config. I'm not sure why devs enjoy reinventing the wheel in incompatible ways all the time. For example: you have Puppet, Chef, Ansible, Salt, etc. They can all make a directory. They do exactly the same thing on almost all systems they support, because POSIX. They literally all just run this syscall: int mkdir(const char pathname, mode_t mode);. But each tool has their own goofy way of being told to make the directory. Why can't I just pass "{'mkdir': [ '/the/path/name', '0700' ]}" to all of them? This is literally all they will be doing, and all they need to know. Just make this path with this permission. This is declarative programming, without a custom language! Anything else, like directory ownership, should be an extra object, like "{'chown': [ '/the/path/name', '1000', '1000' ] }". Again, this is literally called the same way everywhere: int chown(const char pathname, uid_t owner, gid_t group);. You can combine the two into one JSON blob in the output of this config management tool (that's what this GUI really is - a GUI CM with a dashboard). You can have sets of blobs with tags that are discrete reusable pieces of configuration. And every tool can just read them, follow a spec based on POSIX, and execute them.
surenrao 9y ago
Have you tried this https://puphpet.com/ https://puphpet.com/
dmoreno 9y ago
With a system based on plugins and components like Serverboards[1] its quite easy to create new functional areas (screens[2] in Serverboards parlance) as the ones you describe. Some times its more difficult to really round up the ideas to make something useful, than implementing it [2]. If you have specific ideas on how would you like a functionality like that to be, I'm all ears to make it real! [1] https://github.com/serverboards/serverboards/ https://github.com/serverboards/serverboards/ [2] https://serverboards.io/developers/18.01/plugins/screen-definition https://serverboards.io/developers/18.01/plugins/screen-defi...
spc476 9y ago
IBM's SMIT did this, and did this 25 years ago (although it generated shell scripts instead of Terraform/CFN/Ansible/Chef/Salt/Etc you mentioned). You could have SMIT just go ahead and do whatever, or you can have it show you the sequence of commands it would do. And it worked both from the command line and the GUI. I can see no issues with it having a web interface as well.
- jackfraser 9y ago
  It really does feel like we're slowly recreating the mainframe the hard way, doesn't it? Some day soon we'll be rewriting Terraform in LISP and running it on something that might as well be z/OS.

by maxaf 9y ago

Personally I'd much rather see a GUI that can help string together snippets of Terraform/CFN and Ansible/Chef/Puppet/Salt/whathaveyou. A visual IDE for infrastructure automation, if you will.

dalore 9y ago

Doesn't Ansible Tower do this (At least for ansible)?

maxaf 9y ago
I haven't used it personally, but judging by the marketing video Tower is mostly an enterprise dashboard with some self-serve features that allow invocation of Ansible playbooks (or perhaps some larger unit of automation - I've no idea if they made something up just for Tower); but the playbooks would still need to be hand-coded elsewhere.
- dalore 9y ago
  Ahh I thought you meant you got some playbooks/roles/modules written but you have a gui to say which are run where. More of a higher level. But I think I see what you mean and I like the idea. A low level GUI that lets you look up specific tasks in ansible and have it create the playbook for you at the end. That would be pretty cool and not that hard to write actually.
  - epicide 9y ago
    Combined with Ansible Galaxy, I think you get pretty close.

ohples 9y ago

Yeah I also wish there was some good Config Management IDEs. I think someone like InteliJ might be able to make a decent one.

snuxoll 9y ago
If you're doing Puppet then the plugin for IntelliJ works pretty well with Puppet code, including reference checks and all the good stuff you'd expect from a half-decent IDE. Can't say anything about Chef or Salt, but with Ansible you get basically shit for help since the IDE just sees a YAML file and nothing more. This is partially the fault of Ansible though, to be honest, modules being standalone scripts that is cool - but they provide no standardized way to inspect their parameters and outputs beyond documentation.
- kilburn 9y ago
  Ansible's modules documentation is auto-generated from the code. Hence, there is a standardized (across all ansible's modules) way to extract their parameters/outputs. See https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/files/iso_extract.py https://github.com/ansible/ansible/blob/devel/lib/ansible/mo... for example: DOCUMENTATION is a yaml snippet that follows their documentation schema to tell you about all the module's input parameters. EXAMPLES gives you some usage examples. RETURN documents the outputs. A proper IDE plugin could parse those snippets for each module and do some pretty nice autocompletion/inline documentation for you...
ryanschneider 9y ago
The terraform plugin for jetbrains products works really well. It auto completes all the resource types and knows what keys are valid under each one, so will suggest keys and highlight a resource as invalid if it’s missing a required key. I can’t imagine coding terraform plans without it.

sciurus 9y ago

So the idea is that you would choose your changes in the GUI, but instead of actually changing the target, it spits out the required code to do it for you in a repeatable way? I would definitely find that useful for Terraform and Cloudformation. Searching for it, I see that AWS has a tool targeted at that: Cloudformation Designer. https://aws.amazon.com/blogs/aws/new-aws-cloudformation-designer-support-for-more-services/ https://aws.amazon.com/blogs/aws/new-aws-cloudformation-desi... https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

jamiesonbecker 9y ago
Example Cloudformation Designer stack diagram (click View In Designer or scroll down for a screenshot): https://userify.com/docs/enterprise/cloudformation/ https://userify.com/docs/enterprise/cloudformation/ If you have an AWS account, you can actually modify/fork the template on the fly by clicking on one of the objects in the diagram and editing its properties (which edits the YAML CloudFormation template in the background).
0xbadcafebee 9y ago
A better idea would be to spit out a spec that tools could use to perform the thing, and get tools to follow the spec. Unfortunately, even though most tools do virtually the exact same thing, they all use their own incompatible ways to describe it in a config. I'm not sure why devs enjoy reinventing the wheel in incompatible ways all the time. For example: you have Puppet, Chef, Ansible, Salt, etc. They can all make a directory. They do exactly the same thing on almost all systems they support, because POSIX. They literally all just run this syscall: int mkdir(const char pathname, mode_t mode);. But each tool has their own goofy way of being told to make the directory. Why can't I just pass "{'mkdir': [ '/the/path/name', '0700' ]}" to all of them? This is literally all they will be doing, and all they need to know. Just make this path with this permission. This is declarative programming, without a custom language! Anything else, like directory ownership, should be an extra object, like "{'chown': [ '/the/path/name', '1000', '1000' ] }". Again, this is literally called the same way everywhere: int chown(const char pathname, uid_t owner, gid_t group);. You can combine the two into one JSON blob in the output of this config management tool (that's what this GUI really is - a GUI CM with a dashboard). You can have sets of blobs with tags that are discrete reusable pieces of configuration. And every tool can just read them, follow a spec based on POSIX, and execute them.

surenrao 9y ago

Have you tried this https://puphpet.com/ https://puphpet.com/

dmoreno 9y ago

With a system based on plugins and components like Serverboards[1] its quite easy to create new functional areas (screens[2] in Serverboards parlance) as the ones you describe. Some times its more difficult to really round up the ideas to make something useful, than implementing it [2]. If you have specific ideas on how would you like a functionality like that to be, I'm all ears to make it real! [1] https://github.com/serverboards/serverboards/ https://github.com/serverboards/serverboards/ [2] https://serverboards.io/developers/18.01/plugins/screen-definition https://serverboards.io/developers/18.01/plugins/screen-defi...

spc476 9y ago

IBM's SMIT did this, and did this 25 years ago (although it generated shell scripts instead of Terraform/CFN/Ansible/Chef/Salt/Etc you mentioned). You could have SMIT just go ahead and do whatever, or you can have it show you the sequence of commands it would do. And it worked both from the command line and the GUI. I can see no issues with it having a web interface as well.

jackfraser 9y ago
It really does feel like we're slowly recreating the mainframe the hard way, doesn't it? Some day soon we'll be rewriting Terraform in LISP and running it on something that might as well be z/OS.