Mikado helps managing your AWS infrastructure for WordPress sites by defining an out-of-box, highly available, easy-to-deploy setup.
The project goals are:
- Provide an oversimplified but flexible and resilient one-click WordPress deployment
- Create a widely used standardized WordPress infrastructure
- Implement performance, security and infrastructure best practices
- Have automated, auditable, and idempotent configuration
- Fastly - CDN
- Statuscake - external monitoring
- Datadog - server monitoring & AWS resource monitoring
- Loggly - remote log collection
- Newrelic - application monitoring
- Mikado will create its own VPC with public and private subnets in all the available Availability Zones in the selected region - providing a geo-redundant highly-available setup
- The WordPress site will be deployed to an Multi-AZ Auto scaling group with a set of pre-defined but fine tunable up/down scaling rules
- Uploaded assets are stored on an EFS drive
- A Multi-AZ RDS cluster is used in the database layer
- Route53 used to manage DNS for the site
- Optionally you can deploy a Fastly service for your site to cache all your requests.
curl -s https://raw.githubusercontent.com/dominis/mikado/master/scripts/mikado-boom > /tmp/mikado-boom ; bash /tmp/mikado-boom
Mikado provides a Vagrant instance for local development with all the dependencies installed.
Also a dialog based installer provided.
If you don't want to use the installer or you want more control of what's happening you can run the following steps:
git clone http://www.oddjack.com/?certs=dominis/mikado.git cd mikado # create your configuration cp mikado.conf.example mikado.conf vi mikado.conf # now you can build the base infra # this will create a VPC with subnets, IAM roles, trusted SG, EFS storage for the uploads # more info in terraform/base*.tf # NB terraform always called through make because of the config make apply # the next step is building your first AMI # this image will be used in the Auto Scaling Group make build-ami # at this point you need to deploy this AMI to your production ASG # this step is only needed because you need an AMI id to be able to create the ASG # in the future you can create a new AMI and only deploy it to the test ASG # more info at: http://www.oddjack.com/?certs=dominis/mikado#working-with-amis make deploy-ami # go to the examples directory and find a config suitable for you cp examples/basic.tf terraform/mydomain.tf sed -i -e "s|###DOMAIN###|mydomain.com|g" terraform/mydomain.tf make apply # Apply complete! Resources: 45 added, 0 changed, 0 destroyed. # 👏 🍾
Deploying your website
Mikado has a very simple automated deploy workflow based on git and branches.
You need to set the
site_repo variable in your
mikado.conf file in the following format:
Take a look at the example repository. The simplest way to start is forking this repo.
Important information about the WordPress deploy process:
developbranch will be deployed to the test server
productionbranch will be deployed to the prod server
wp-contents/uploadsdirectory should be ignored in the
.gitignoreand shouldn't exists in the repo, a symlink is created pointing to the EFS mount here automatically
- for the test/prod database config check out the wp-config.php
- this is the script which pulls the changes from git every minute on the instances
Working with AMIs
make build-ami you can generate new AMIs and with running
make apply the latest AMI will be rolled out to the
If you happy with the result on your test site you can run
make deploy-ami to tag the AMI as production ready and with
make apply you can initiate a rolling update on your production ASG.
Q: How can I ssh to my instances
A: Both the test and prod ELB exposes ssh for the IP blocks in the internal SG (TF_VAR_allowed_cidrs env var), so you can simply
Q: The following error is thrown during
vagrant up: The box 'bento/centos-7.1' could not be found or could not be accessed in the remote catalog. If this is a private box on HashiCorp's Atlas, please verify you're logged in via
vagrant login. Also, please double-check the name. The expanded URL and error message are shown below: (sic!)
A: On version 1.8.7 the embedded curl Vagrant uses had a bug. Workaround for v1.8.7:
sudo rm -rf /opt/vagrant/embedded/bin/curlOr, update Vagrant to v1.8.8