we operate Kubernetes as follows to try and minimise it:
- We run multiple production clusters and teams are able to choose which clusters to run their application in. We don’t use Federation yet (we’re waiting on AWS support) but we use Envoy instead to load-balance across the different cluster Ingress load-balancers. We can automate much of this with our Continuous Delivery pipeline (we use Drone) and other AWS services.
- All clusters are configured with the same Namespaces. These map approximately 1:1 with teams.
- We use RBAC to control access to Namespaces. All access is authenticated and authorised against our corporate identity in Active Directory.
- Clusters are auto-scaled and we do as much as we can to optimise node start-up time.
- Applications auto-scale using application-level metrics exported from Prometheus.
Not very insightful, but I'm retaining some quotes:
But IT operations includes much more than the limited “ops” functions we typically fold into a DevOps team. I’m talking about things like ticket management, incident handling, user management and authorization, backups and recovery, network management, security operations, infrastructure procurement and cost optimization, compliance reporting, and much more. In today’s IT organization, where do these responsibilities fall?
You want DevOps teams to have a streamlined, low lead-time, lean pipeline to production. Devoting team capacity to this broader set of operational functions may slow down this pipeline. There are also efficiencies to be gained by sharing these practices across the work of all the DevOps teams.
All of this is to say that a portion of IT operations still exists independently of the DevOps teams, performing those “ops” functions that are not in “DevOps” while the DevOps teams focus on that subset of ops functions specifically related to deploying code and responding to code-related incidents
Speed, reproducibility, easy rollbacks, and predictability is what we strive for when deploying our diverse Python applications. And that’s what we achieved by leveraging virtual environments and Linux system packages.
-
"Ansible is simple, which is a major strength", it "works by connecting to a server using SSH, copies the Python code over, executes it and then removes itself".
"Ansible Tower is the Enterprise version, it turns the command line Ansible into a service, with a web interface, scheduler and notification system."
"you can’t have long-running tasks." -
"StackStorm is designed as a highly-configurable if-this-then-that service. it can react to events and then run a simple command or a complex workflow."
"MongoDB can be scaled using well-documented patterns." "StackStorm extensibility system is a key strength." "If StackStorm were a programming language, it would be strongly typed." -
"Salt was born as a distributed remote execution system used to execute commands and query data on remote nodes."
"Ultra high-performance for large deployments." (LinkedIn use it)
st2 - StackStorm (aka "IFTTT for Ops") is event-driven automation commonly used for auto-remediation, security responses, facilitated troubleshooting, complex deployments, and more. Includes rules engine, workflow, 1500+ integrations, native ChatOps and so forth. Zingy installer available at http://docs.stackstorm.com/install/index.html. Ping us on slack - https://stackstorm-community.slack.com/.
wercker - automation driven development
CloudSlang is a flow-based orchestration tool for managing your deployed applications.
Rapidly automate your DevOps use cases using ready-made workflows.
The Puppet Language Style GuideMetadataPuppet Language Style Guide: Version 2.0.1Puppet: Version 3.7+ (Note: While the style guide maps to Puppet 3.7, many of its recommendations apply to Puppet 3.0.x an...
small-deployer - Githook client, in rust.
debops - Your Debian-based data center in a box -
How to run docker containers on your desktop.
Go continuous delivery software helps in continuous deployment and software release automation to help enterprises deliver higher quality software
Confusion slows your team down. Slowing your team down makes another team angry because they’re waiting on that update to the platform to deploy their new application. Others are frustrated that we’re all cutting corners with security. Breaking SecDevOps is easy, see?
Many reasons why you should stop using Docker