tweak sizes, minor fixes

chapters/01-introduction.md

@@ -13,7 +13,7 @@ This book is open source:
 Published on the Semaphore website:
 [https://semaphoreci.com](https://semaphoreci.com/?utm_source=ebook&utm_medium=pdf&utm_campaign=cicd-docker-kubernetes-semaphore)
 
-$MONTHYEAR: Second edition v1.1 (revision $REVISION)
+$MONTHYEAR: Second edition v2.0 (revision $REVISION)
 
 \newpage
 

chapters/07-tutorial-clouds.md

@@ -10,15 +10,14 @@ We’ll deploy the application in a three-node Kubernetes cluster. You can pick
 
 ### 4.5.1 DigitalOcean Cluster
 
-DigitalOcean provides everything needed to deploy the application: a managed Kubernetes, a Container Registry, and Postgres databases. 
+DigitalOcean provides everything needed to deploy the application: a managed Kubernetes, a Container Registry, and Postgres databases.
 
 To create the Kubernetes cluster:
 
   - Sign up or log in to your account on [digitalocean.com](https://www.digitalocean.com).
   - Create a *New Project*.
   - Create a *Kubernetes* cluster: select the latest version and choose one of the available regions. Name your cluster “semaphore-demo-cicd-kubernetes”.
   -  While DigitalOcean is working on the cluster, go to *API* menu and generate a *Personal Access Token* with Read & Write permissions.
-  - To finalize, go to *Container Registry* and create a starter repository. Set the repository name, which is globally unique, and remember it for the next chapter.
 
 Next, create a Container Registry with the following actions:
 
@@ -45,7 +44,7 @@ Google Cloud calls its service *Kubernetes Engine*. To create the services:
   - Name your cluster “semaphore-demo-cicd-kubernetes”.
   - Go to *IAM* \> *Service Accounts*.
   - Generate an account Basic > Owner role.
-  - Click on the menu for the new roles, select *Manage Keys* > *Add Keys*. 
+  - Click on the menu for the new roles, select *Manage Keys* > *Add Keys*.
   - Generate and download a **JSON** Access Key file.
 
 On Semaphore, create a secret for your Google Cloud Access Key file:
@@ -132,9 +131,9 @@ Once the cloud database is running:
 ### 4.6.3 AWS Database
 
   - Find the service called *RDS*.
-  - Create a PostgreSQL database called “demo” and type in a secure password.
-  - Choose the same region where the cluster is running.
-  - Select one of the available *templates*. The free tier is perfect for demoing the application. Under *Connectivity* select all the VPCs and subnets where the cluster is running (they should have appeared in eksctl’s output).
+  - Create a PostgreSQL database (choose Standard Create) and call it “demo”. Type in a secure password for the `postgres` account.
+  - Select one of the available *templates*. The dev/test option is perfect for demoing the application. Under *Connectivity* select all the VPCs and subnets where the cluster is running (they should have appeared in eksctl’s output).
+  - In Availability Zone, select the same region the Kubernetes cluster is running.
   - Under *Connectivity & Security* take note of the endpoint address
     and port.
 

chapters/08-tutorial-deployment.md

@@ -27,11 +27,11 @@ Below the promotion options, click on *+ Add Environment Variables* to create a
 
 The parameter we're going to add is going to let us specify the number of Canary pods to deploy. Set the variable name to `CANARY_PODS`, ensure that "This is a required parameter" is checked and type "1" in default value.
 
-![](./figures/08-param1.png){ width=60% }
+![](./figures/08-param1.png){ width=70% }
 
 Create a second parameter called `STABLE_PODS`. Set the default value to "2".
 
-![](./figures/08-param2.png){ width=60% }
+![](./figures/08-param2.png){ width=70% }
 
 In the new pipeline, click on the first block. Let's call it “Push”. The push block takes the Docker image that we built earlier and uploads it to the private Container Registry. The secrets and the login command will vary depending on the cloud of choice.
 
@@ -133,7 +133,7 @@ Create a new pipeline (using the *Add promotion* button) branching out from the
 
 Add a parameter called `$STABLE_PODS` with default value "3".
 
-![](./figures/08-param3.png){ width=60% }
+![](./figures/08-param3.png){ width=70% }
 
 Create the “Deploy to Kubernetes” block with the `do-key` and `db-params` secrets. Also, create the `CLUSTER_NAME` and `REGISTRY_NAME` variables as we did in the previous step.
 
@@ -169,7 +169,7 @@ Wait until the CI pipeline is done an click on *Promote* to start the canary pip
 
 [^no-autopromotion]: You might be wondering why the automatic promotion hasn’t kicked in for the canary pipeline. The reason is that we set it to trigger only for the master branch, and the Workflow Builder by default saves all its changes on a separate branch called `setup-semaphore`.
 
-![Canary Promote](./figures/08-promote1.png){ width=95% }
+![Canary Promote](./figures/08-promote1.png){ width=70% }
 
 Press *Start Promotion* to run the canary pipeline.
 
@@ -309,7 +309,7 @@ The first four lines print out information about the cluster. The last two, undo
 
 Run the workflow once more and make a canary release, but this time try rollback pipeline by clicking on its promote button:
 
-![Rollback Pipeline](./figures/05-sem-rollback-canary.png){ width=60% }
+![Rollback Pipeline](./figures/05-sem-rollback-canary.png){ width=95% }
 
 And we’re back to normal, phew\! Now its time to check the job logs to see what went wrong and fix it before merging to master again.