This tutorial explains how to manually provision an AWS EC2 virtual machine using Ansible. Before you start, you should be familiar with the following concepts:
In light of a recent blog post about a competitor's security vulnerabilities, I wanted to be completely transparent about our security best practices to reassure our customers that they're in good hands.
From the start, we've been very aware of the fact that when customers click on the Authorize button to grant us access to their GitHub or Bitbucket repositories, they trust us with their Intellectual Property. This is a tremendous step, especially since we're all aware of hackers attacking almost every major site and stealing personal information.
Our security measures fall under two pillars, Product and Process, both of which are explained below.
If you google "matrix from hell", you'll see many articles about how Docker solves the matrix from hell. So what is the matrix from hell? Put simply, it is the challenge of packaging any application, regardless of language/frameworks/dependencies, so that it can run on any cloud, regardless of operating systems/hardware/infrastructure.
The original matrix from hell: applications were tightly coupled with underlying hardware
Docker solved for the matrix from hell by decoupling the application from the underlying operating system and hardware. It did this by packaging all dependencies inside Docker containers, including the OS. This makes Docker containers "portable", i,e, they can run on any cloud or machine without the dreaded "it works on this machine" problems. This is the single biggest reason Docker is considered the hottest new technology of the last decade.
With DevOps principles gaining center stage over the last few years, Ops teams have started automating their tasks like provisioning infrastructure, managing config, triggering production deployments, etc. IT automation tools like Ansible and Terraform help tremendously with these use cases since they allow you to represent your infrastructure-as-code, which can be versioned and committed to source control. Most of these tools are configured with a YAML or JSON based language which describes the activity you're trying to achieve.
What's in a name? wrote the greatest Bard that ever lived.
He was wrong. If someone ever asked me a hypothetical question about which dead person I'd want to have a conversation with, it'll definitely be Shakespeare. Let me explain why.
When we launched Shippable Pipelines last year, we wanted to highlight the difference between plain vanilla CI and the capability to put together a deployment "pipeline" that spans orchestration across multiple environments and supports all tasks involved in software delivery like CI, infrastructure provisioning, test automation, deployments, security patching, release management, config mgmt, service discovery, etc.
However, shortly after we launched, other CI providers launched their own interpretations of "pipelines"! For example,
How did everyone come to the same exact place so rapidly? As we found out, they didn't. Pipelines was being used as a fancy name for CI, with features that Shippable had supported for over two years, like Matrix builds for splitting tests or testing against multiple environments for example.
We needed a way to explain why Shippable is different. This blog explains why we landed on DevOps Assembly Lines as the perfect way to describe our approach to DevOps and CI/CD.