Configuring dev and prod env

Provisioning and code deploys for our stack. Local dev workstations, staging, and production.

Provisioning + deployment with huge community repository.

All of our servers are provisioned by Ansible, with no manual provisioning involved. This lets us easily roll out new servers, with no chance for human error when configuring the servers. We use the same code to provision local development environments on Vagrant, which eliminates configuration discrepancies between development and production.

Recipes for deployment (git calls, system set-up & upgrades)

Our core infrastructure as code engine

Ansible is the deployment tool for people who don't like deployment tools. It's close to scripting, doesn't pollute your servers with agents or centralized servers, and just makes immediate sense. The entire stack at Cloudcraft.co is orchestrated by Ansible. What does that mean? Beyond the obvious of installing packages and configuring services, Ansible coordinates all the machines into a working deployment: It adds API servers to the loadbancer pool, opens ports on the DB server for the backend servers to connect, gracefully upgrades services in a rolling fashion for zero-downtime deployments etc. And it's so easy to use, it's easier to use than doing things by hand, meaning it's a deployment tool you'll actually use every time!

Server configuration tool for me. Simple and ultra lightweight.

Automate everything with Ansible

Provision and deploy.

VPN deployment

some deployment configuration and provisioning vagrant like in deployment

The magic tool behind one person managing a cluster of tons of servers!

To do less, but get more done on our servers.

Deployment tool for the services and the flask application

We do single click deployment with Ansible

Because managing many machine by hand is bad for productivity and horrible for the colleague.

Automate all the things!

Used mainly with Vagrant Provision to setup dev environment.

Configuration and manage the OS and the bigdata software.

Ansible is used in both the development and production deployment process. A playbook couple with a Vagrantfile, easy deploys a local virtual machine that will mirror the setup in production.

I use Ansible to manage the configuration between all of the different pieces of equipment, and because it's agentless I can even manage things like networking devices all from one repo.

Build, test, deployment and server management.

Server deployment and software updates.

Super simple, Agentless Infrastructure as Code

Network and Server Orchestration backend with PHP Web Frontend (AnsNet)

We use Ansible for deployments and configuration management to ensure that our systems are all setup consistently.

We use Ansible to synchronize the few configuration-options we've taken on our CoreOS-Machines. This makes deployment even easier and the fact that it's Agentless made the decision even easier.

• Configuration management:
  • deploy/install all web/app environments
  • simple with Galaxy and playbooks.
• No need any pre-installed agent on remote servers.

We stick to puppet & our own APT repository. We don't use Ansible.

Orchestrate deployment of monolith.

Infrastructure automation

Kind of tough to learn a mix of YAML syntax and Python stuff, but playing a key role in our deployment process.

I'm using puppet to configure my servers. This makes it really simple to ensure that I have the same environment. There is a bit of a learning curve, but the repeatability definitely makes it worth the effort. I found puppet to be a little easier to pick up relative to chef, but I've used both. They're both great solutions.

I really like that there are a lot of modules available on the puppet forge that are being actively maintained.

Opstax uses puppet for role/profile based configuration management and the distribution of small/static code.

The server is set up using Puppet

Configures or servers and allows us to be region independent we have 5 regions across the globe.

We provision all servers with puppet. We have one central Puppet server which uses puppet modules referenced by a Puppetfile. Those puppet modules are partly from forge and partly self written.

All modules which are self written, have to be tested using rspec-puppet and beaker.