Would Salt be willing to support an open usage concept?

[howardroark]

I am self-taught developer who works in advertising. Up until a few years ago I would have called myself a front-end developer and stayed away from opportunities that involved Linux. A lot of money is spent on technology in the marketing industry and most developers have entered the workforce by teaching themselves.

Up until the recent boom of open-source operational tools and cloud APIs it made no sense for any company to use a setup more complicated than a LAMP stack with a control panel. There is a huge market of flexible and industry savvy PHP/JS developers to hire from in any major city. It just makes sense to build whatever you need with MAMP and upload it via FTP later. At the same time though the node.js movement is reinventing workflows for building web applications in smart and efficient ways. Be it small RESTful frameworks or static site generators, it all has a focus on community and growth.

The biggest barrier of entry for node based web development is Linux and the myriad of configuration strategies. Vagrant and smart Salt configurations can help get developers running without stress as they learn the Linux ecosystem. At the same time the cloud is getting cheaper and easier to maneuver with clever automation. Tools like Salt and Docker keep making the process more simple and community driven.

The best part about Salt is how decentralized it is by design. When using Salt for development purposes it is easiest just to do everything in a minion only setup. Though you still end up keeping a large majority of your states in a shared repo with helpful marcos. It would be nice to accomplish this process with Formulas and contribute to the larger effort, but they require a master-minion setup to work effectively.

With all that being said I have for a long time wanted to run a salt-master that any salt minion could pair with, be it VirtualBox or AWS. The minions themselves would be self sufficient and understand that the "master" is just a place to leverage configuration macros and salt formulas. The service would be a pure convenience that enables a community to write and build configurations that work best in the marketing world. Marketing initiatives would rarely need a cluster of servers and usually have short life spans. It is more an effort to ensure that Linux web applications are built in a sane way with best practices in mind.

Would Salt be willing to support and officially document an open use master concept like this? I am not an expert but I would love to get more people using virtualization and Salt rather than defaulting to Wordpress and Cpanel. I'm sure there is a plethora of security concerns and operational implications to be aware of, but why not figure out what they are and write them down. The more people talking about Salt the better, no? ;) Not everyone can hire a dev ops expert, but anyone can ease into the landscape with a little help.

I know there is an open_mode setting, but I would hesitate to use it in this manner unless Salt itself was aware of it and supported the strategy. In theory at least.

I'd call it the "mother" setup. The idea being that the minions would have to trust that the mother server always had their best interests in mind. At the same time the mother server would always want the minions to be self sufficient and be capable of taking care of themselves.

[whiteinge]

Welcome! Very interesting high-level question here.

It sounds like you're describing a sort of Salt-master-as-a-service scenario. I think Salt can be configured to do most or maybe even all of this already in it's current form. The remaining questions probably all center around (as you pointed out) defining and documenting the security concerns and operational implications.

I have a few follow-up questions for you:

It would be nice to accomplish this process with Formulas and contribute to the larger effort, but they require a master-minion setup to work effectively.

There is indeed a lot of win invoking Salt in a decentralized manner (locally) but still making use of a central authority to distribute configuration files, Salt formulas, and other data. In fact, the file server part of Salt works great without a running minion daemon. (The master still needs to have accepted the minion key though.) In a minion-centric set up like this, the only thing you'd need a running minion daemon for is for sharing data or events with other minions.

At the same time the mother server would always want the minions to be self sufficient and be capable of taking care of themselves.

What are you thinking is the full scope of the mother server's duties in this configuration? Serving files and formulas obviously. Anything else? Would the minions categorize themselves or be automatically categorized when calling out to the mother? (E.g., saying "I am a staging webserver", or asking "what am I?".)

[howardroark]

Thanks a lot for this reply, it sounds like you have had some of these thoughts before! Salt-master-as-a-service is exactly how I would describe it to another Salt user. Also, just like you described it would be a collection of states, formulas and other data that enable common web app setups. The idea would be to allow developers to use templates of project setups and modify the minion state data to suit their needs. The trick would be to avoid the pki keys or get the process as seamless as possible. It would need to be as simple as running vagrant up after cloning a repo with a Vagrantfile and some Salt config. The beauty here is that the server config is able to evolve with the project as the requirements change.

In terms of the duties of the "mother" server, it would be aware of the category of the minion (vagrant, staging, production). Apart from offering configuration, I can't think of what else it would do. I really don't use Salt in the way a systems administrator would. If the mother server had the ability to upgrade things on the minion, that could have advantages. The internet already deals with the issue of stale Wordpress and Rails sites left in the cloud. The minion config could contain contact info that the "mother" service could reach out to if it felt a server was using unsafe packages.

My plan as of now...

1. Get comfy with Docker.
2. Create packer scripts to build out Ubuntu 12.04 Vagrant and AWS boxes with Salt and Docker.
3. Build a Salt master docker image that is set to open mode.
4. When initiating a Vagrant machine load the Salt master Docker image and run the minion against it.
5. Smash my head until it works.

I figure this way the Docker image of the Salt master becomes the proof of concept. I ideally you could set your minion to use an existing service or deploy your own.

Again, thanks for the well considered reply.