|
| 1 | +# DevStack |
1 | 2 |
|
| 3 | +DevStack is intended for the DevOps engineer who finds her/him self constantly jumping between different DevOps enterprise tools to deliver new solutions. |
2 | 4 |
|
3 | | -## Setup of test Environment |
| 5 | +DevStack gives you simple to reuse groovy classes for spinning up new test environments in a local or remote docker engine and automates the basic setup of the individual tool. |
4 | 6 |
|
5 | | -//TODO add info about license files |
| 7 | +## What does it really do? |
6 | 8 |
|
7 | | -1. Setup certs in resources/dockerCert |
| 9 | +DevStack creates local or remote docker containers, sets up docker level networking, spins up the container with sensible settings and configures the basic settings needed inside the tool to get it up and running. |
| 10 | + |
| 11 | +Example: [JsmAndBitbucketH2Deployment.groovy](src%2Fmain%2Fgroovy%2Fcom%2Feficode%2Fdevstack%2Fdeployment%2Fimpl%2FJsmAndBitbucketH2Deployment.groovy) |
| 12 | + |
| 13 | +This class will help you spin up JIRA and Bitbucket containers in the same docker network, configure sensible JAVA environment variables, setup DBs for both applications, install JIRA apps and create an Application Link between them. |
| 14 | + |
| 15 | +## Pros/Cons |
| 16 | + |
| 17 | +### Pro |
| 18 | +* Facilitate testing of complex setups |
| 19 | + * Got a complex flow involving Jira, Bitbucket, Jenkins, Harbor and now you are afraid of upgrading? |
| 20 | + * Integrate DevStack in your Spock test, configure it to spin up a mirror of your environment and the flow. Tweak the version used and run your test. |
| 21 | +* Takes over after Docker has done its thing. |
| 22 | + * Docker is great for starting an application like JIRA but then it´s up to you (or DevStack) to setup, DB, Apps, Admin accounts, licenses. |
| 23 | +* Move away from Snowflake test environments, test your changes in fresh environments every time. |
| 24 | +* DevStack can use local or remote Docker engines, making running the tests locally on your machine easy while still offloading the heavy lifting to a cloud Docker Engine. |
| 25 | + |
| 26 | +### Cons |
| 27 | +* DevStack is not intended for production use ever, it should only be used for short-lived test environments with nothing to loose. |
| 28 | +* Not intended for existing environments, presumes DevStack was used to setup up the environment. |
| 29 | + |
| 30 | +# Setup Docker Engine in AWS |
| 31 | + |
| 32 | +DevStack defaults to trying to connect to a local Docker engine, but a terraform project is supplied for setting up a remote EC2 with docker engine. The docker engine will be configured to only accept HTTPS from your IP. |
| 33 | + |
| 34 | +### Requirements: |
| 35 | + * An AWS account with no vital data |
| 36 | + * With corresponding Access and Secret key: [Check guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) |
| 37 | + * CA, Server and Client certs |
| 38 | + * This script can be used for generating the Certs: [createCerts](https://gist.github.com/farthinder/9df3019e2e01cdd167dd02abf7d5f903) |
| 39 | + * SSH Keys |
| 40 | + |
| 41 | +1. Setup Docker Engine certs in ~/.docker/ |
8 | 42 | * ca.pem: A ca cert that signed the other certs |
9 | | - * cert.pem & key.pem: Public and private keys to be used by docker client |
10 | | - * server-cert.pem & server-key.pem: Public and private keys to be used by docker server. Should be setup for domain name: docker.domain.se |
| 43 | + * server-cert.pem & server-key.pem: Public and private keys to be used by docker server. By convention DevStack uses: docker.domain.se, but anything is fine aslong as you can put it in your hosts file. |
| 44 | + * ~/.docker/ is the default place but can be changed in [variables.tf](Environments%2FAWS%2Fvariables.tf) |
| 45 | + |
| 46 | +2. Setup Docker Client certs in ~/.docker/ |
| 47 | + * ca.pem: A ca cert that signed the other certs (same as in step 1) |
| 48 | + * cert.pem & key.pem: Public and private keys to be used by docker client |
| 49 | + * The ~/.docker/ location is arbitrary and ultimately determined by you when you instantiate DevStack classes. |
11 | 50 |
|
12 | | -2. Set up an AWS account with high (admin) privileges in an ISOLATED test account *WITH NO VITAL SETUPS* |
| 51 | +3. Set up an AWS account with high (admin) privileges in an ISOLATED test account *WITH NO VITAL DATA* |
13 | 52 | * Get Access Key and Secret Key for the account |
14 | | - * Update *aws_credentials* in Environments/Terraform/variables.tf |
| 53 | + * Update *aws_credentials* in Environments/AWS/variables.tf |
15 | 54 |
|
16 | | -3. Make sure you have a valid public SSH key in ~/.ssh/id_rsa.pub |
17 | | - * Or update *ssh-public-key-local-path* in Environments/Terraform/variables.tf |
| 55 | +4. Make sure you have a valid public SSH key in ~/.ssh/id_rsa.pub |
| 56 | + * Or update *ssh-public-key-local-path* in Environments/AWS/variables.tf |
18 | 57 |
|
19 | | -4. Update *trusted-external-ips* in Environments/Terraform/variables.tf |
| 58 | +5. Update *trusted-external-ips* in Environments/AWS/variables.tf |
20 | 59 | * This should normally be set to your external ip, check for example: https://whatismyipaddress.com |
21 | 60 |
|
22 | | -5. Go to Environments/Terraform and run terraform apply |
| 61 | +6. Go to Environments/Terraform and run terraform apply |
23 | 62 | * Note the "Hosts-record" output, this needs to be added to your /etc/hosts |
24 | 63 |
|
25 | 64 |
|
|
0 commit comments