5 ms·

How much more flapping there needs to be? Chef, Puppet, Ansible, Salt, Vagrant, Docker, CoreOS, runC, Kubernetes, OpenStack, the list goes on and on and on. Peo

by Annatar 10y ago

How much more flapping there needs to be? Chef, Puppet, Ansible, Salt, Vagrant, Docker, CoreOS, runC, Kubernetes, OpenStack, the list goes on and on and on. People are going way, waaayyy out of their way just so they wouldn't learn shell programmimg and how to build all this automation with OS packages. Is learning N amounts of discrete orchestration really easier and simpler than writing shell scripts and encapsulating them in OS packaging? Seriously?!? Enough with the flapping and discrete solutions already!!!

aisofteng 10y ago
While I understand where you're coming from, I expect that if you've had to manage application deployment and configuration in a large-scale environment you would be quite aware of how much work it is to develop even a one-off robust solution that is fully tested for edge cases, let alone reusable.
- Annatar 10y ago
  I currently run close to 72,000 servers doing automated deployment and configuration management with nothing but OS packaging and shell code inside of those packages. Does that qualify as large enough?
  - pawadu 10y ago
    Thank you! I had always assumed these tools felt over-engineered to me because I don't work with very large deployments. Now I am certain they ARE over-engineered...
  - lisivka 10y ago
    I doing same: shell scripts (or Perl/Python/C) and RPM packages. Works well for more than decade. But I use my own library of modules for bash (bash-modules project on GitHub).
xref 10y ago
Exactly! And how about all the flapping in languages; C, C++, Java, Python, Ruby, JavaScript, C#, Go, Swift and the list goes on and on. People are going way, waaayyy out of their way just so they wouldn't learn shell programmimg. Is learning N different languages really easier and simpler than writing shell scripts? Seriously?!? I run close to 72,000 servers and I won't deploy any code on them except shell code. Enough with the flapping languages already!
- deleted 10y ago
  [deleted]
deleted 10y ago
[deleted]
mwpmaybe 10y ago
I'm not sure what you mean by "flapping," but the technologies in your list do not all address the same problem space. You might as well ask why we need both Solaris and C++. Only the first four (Chef, Puppet, Ansible, and Salt) are configuration management tools, which take the place of "writing shell scripts and encapsulating them in OS packaging." If you're well-versed in one, there's no need (short of a job change) to learn the others. Vagrant allows you to create reproducible development environments using shell scripts (by default), so it should be right up your ally. Docker is used to containerize applications. runC is the container runtime used by Docker. Kubernetes orchestrates containerized applications across a fleet of CoreOS (a minimal "Docker host" Linux) machines. OpenStack orchestrates your data center. They are discrete solutions because they do different things. Each piece of the puzzle does one thing and (hopefully) does it well. That philosophy should sound familiar to you! Back to "writing shell scripts and encapsulating them in OS packaging": have you tried a configuration management tool? I used to be old school like you; specifically, maintaining a fleet of AIX instances using a healthy mix of Perl, ksh, and RPM. I too was resistant to the tide of new, quickly-evolving technologies. I started using Ansible about a year ago and it's changed my life. Don't be so quick to pooh pooh the idea that there just might be a better way to do things.
- Annatar 10y ago
  I'm not sure what you mean by "flapping," Flapping, you know, when a person who cannot swim is drowning and just flailing and flapping their body, most notably arms, all over the place in an attempt to stay above water so that they do not drown. but the technologies in your list do not all address the same problem space. I don't know about you, but for me to get a fully configured, ready-to-serve system, I need both provisioning and configuration management. With that being the case, provisioning and configuration management fall under the same problem domain. Vagrant allows you to create reproducible development environments using shell scripts (by default), so it should be right up your ally. Docker is used to containerize applications. runC is the container runtime used by Docker. Kubernetes orchestrates containerized applications across a fleet of CoreOS (a minimal "Docker host" Linux) machines. OpenStack orchestrates your data center. They are discrete solutions because they do different things. Each piece of the puzzle does one thing and (hopefully) does it well. That philosophy should sound familiar to you! I'm familiar with all of those technologies, and yes it does indeed sound familiar to me! But, what is unclear to me is, why I would use a discrete provisioning solution like Kubernetes instead of using, say, imgadm(1M) and vmadm(1M) through parallel SSH? Why would I use a discrete, proprietary solution like Vagrant when I wrote my own, simple variable expansion function which uses eval(1), and that's all that's really needed for configuration management? I'm far, far better off with a simple shell function then using Salt or Ansible. Simplicity, the core of the UNIX principle. eval(1) is much simpler and easier to understand than an entire provisioning and/or configuration management engine! Or do you disagree? Other than templated configuration excerpts and self-assembly, both easily implemented with a few simple lines of shell code in a small shell library which OS packages can source, what more do I need to configure systems? Why make things unnecessarily complex? In fact, that exact same approach is what Chef uses, conceptually, when one specifies the configuration management policy, except that with my solution, the system administrator need not learn a proprietary Ruby dialect and need not employ a client-server architecture; they can just dive in and leverage their existing shell programming knowledge, with a zero learning curve. And because it's all just shell and AWK, the system administrator has infinite possibilities to configure the systems and do anything they need to do, without being limited by the framework of whichever technology they are using (like YAML or Chef recipes). So why bother??? Why flap? Why would I need runC and Docker to provision systems, if I can just install OS packages which configure the system, and then make a ZFS image? Or, in terms of Linux: why do I need say Docker and Kubernetes, if I have everything in OS packages, and I just use KickStart to PXE boot, automatically install and configure the target node with OS packages? have you tried a configuration management tool? You bet your ass I did! But that's not the point, the point is, why should I learn a discrete, proprietary systems, when I can just write a simple shell library which leverages the eval(1) command to do variable expansion, and BAM!!! I instantenously have a template expansion engine so all my configuration, even code, can be parametrized using the same varaible evaluation and expansion technology which the shell uses, and which the configuration packages can call? With that: - I don't have to use proprietary, discrete systems; - I can leverage technology already built into the operating system; - I don't need a client-server architecture like Chef or Puppet, ever (ssh-sshd is just fine, thank you!) Why would anyone waste their time?

by Annatar 10y ago

aisofteng 10y ago

While I understand where you're coming from, I expect that if you've had to manage application deployment and configuration in a large-scale environment you would be quite aware of how much work it is to develop even a one-off robust solution that is fully tested for edge cases, let alone reusable.

Annatar 10y ago
I currently run close to 72,000 servers doing automated deployment and configuration management with nothing but OS packaging and shell code inside of those packages. Does that qualify as large enough?
- pawadu 10y ago
  Thank you! I had always assumed these tools felt over-engineered to me because I don't work with very large deployments. Now I am certain they ARE over-engineered...
- lisivka 10y ago
  I doing same: shell scripts (or Perl/Python/C) and RPM packages. Works well for more than decade. But I use my own library of modules for bash (bash-modules project on GitHub).

xref 10y ago

Exactly! And how about all the flapping in languages; C, C++, Java, Python, Ruby, JavaScript, C#, Go, Swift and the list goes on and on. People are going way, waaayyy out of their way just so they wouldn't learn shell programmimg. Is learning N different languages really easier and simpler than writing shell scripts? Seriously?!? I run close to 72,000 servers and I won't deploy any code on them except shell code. Enough with the flapping languages already!

deleted 10y ago
[deleted]

deleted 10y ago

[deleted]

mwpmaybe 10y ago

I'm not sure what you mean by "flapping," but the technologies in your list do not all address the same problem space. You might as well ask why we need both Solaris and C++. Only the first four (Chef, Puppet, Ansible, and Salt) are configuration management tools, which take the place of "writing shell scripts and encapsulating them in OS packaging." If you're well-versed in one, there's no need (short of a job change) to learn the others. Vagrant allows you to create reproducible development environments using shell scripts (by default), so it should be right up your ally. Docker is used to containerize applications. runC is the container runtime used by Docker. Kubernetes orchestrates containerized applications across a fleet of CoreOS (a minimal "Docker host" Linux) machines. OpenStack orchestrates your data center. They are discrete solutions because they do different things. Each piece of the puzzle does one thing and (hopefully) does it well. That philosophy should sound familiar to you! Back to "writing shell scripts and encapsulating them in OS packaging": have you tried a configuration management tool? I used to be old school like you; specifically, maintaining a fleet of AIX instances using a healthy mix of Perl, ksh, and RPM. I too was resistant to the tide of new, quickly-evolving technologies. I started using Ansible about a year ago and it's changed my life. Don't be so quick to pooh pooh the idea that there just might be a better way to do things.

Annatar 10y ago
I'm not sure what you mean by "flapping," Flapping, you know, when a person who cannot swim is drowning and just flailing and flapping their body, most notably arms, all over the place in an attempt to stay above water so that they do not drown. but the technologies in your list do not all address the same problem space. I don't know about you, but for me to get a fully configured, ready-to-serve system, I need both provisioning and configuration management. With that being the case, provisioning and configuration management fall under the same problem domain. Vagrant allows you to create reproducible development environments using shell scripts (by default), so it should be right up your ally. Docker is used to containerize applications. runC is the container runtime used by Docker. Kubernetes orchestrates containerized applications across a fleet of CoreOS (a minimal "Docker host" Linux) machines. OpenStack orchestrates your data center. They are discrete solutions because they do different things. Each piece of the puzzle does one thing and (hopefully) does it well. That philosophy should sound familiar to you! I'm familiar with all of those technologies, and yes it does indeed sound familiar to me! But, what is unclear to me is, why I would use a discrete provisioning solution like Kubernetes instead of using, say, imgadm(1M) and vmadm(1M) through parallel SSH? Why would I use a discrete, proprietary solution like Vagrant when I wrote my own, simple variable expansion function which uses eval(1), and that's all that's really needed for configuration management? I'm far, far better off with a simple shell function then using Salt or Ansible. Simplicity, the core of the UNIX principle. eval(1) is much simpler and easier to understand than an entire provisioning and/or configuration management engine! Or do you disagree? Other than templated configuration excerpts and self-assembly, both easily implemented with a few simple lines of shell code in a small shell library which OS packages can source, what more do I need to configure systems? Why make things unnecessarily complex? In fact, that exact same approach is what Chef uses, conceptually, when one specifies the configuration management policy, except that with my solution, the system administrator need not learn a proprietary Ruby dialect and need not employ a client-server architecture; they can just dive in and leverage their existing shell programming knowledge, with a zero learning curve. And because it's all just shell and AWK, the system administrator has infinite possibilities to configure the systems and do anything they need to do, without being limited by the framework of whichever technology they are using (like YAML or Chef recipes). So why bother??? Why flap? Why would I need runC and Docker to provision systems, if I can just install OS packages which configure the system, and then make a ZFS image? Or, in terms of Linux: why do I need say Docker and Kubernetes, if I have everything in OS packages, and I just use KickStart to PXE boot, automatically install and configure the target node with OS packages? have you tried a configuration management tool? You bet your ass I did! But that's not the point, the point is, why should I learn a discrete, proprietary systems, when I can just write a simple shell library which leverages the eval(1) command to do variable expansion, and BAM!!! I instantenously have a template expansion engine so all my configuration, even code, can be parametrized using the same varaible evaluation and expansion technology which the shell uses, and which the configuration packages can call? With that: - I don't have to use proprietary, discrete systems; - I can leverage technology already built into the operating system; - I don't need a client-server architecture like Chef or Puppet, ever (ssh-sshd is just fine, thank you!) Why would anyone waste their time?