Increase image width to 95%.

chapters/03-kubernetes-deployment.md

@@ -484,7 +484,7 @@ reasons to do that, including:
   as possible, without even waiting for the old set of containers
   to restart.
 
-![Blue/Green Deployment](figures/03-blue-green.png){ width=70% }
+![Blue/Green Deployment](figures/03-blue-green.png){ width=95% }
 
 You can achieve blue/green deployment by creating multiple
 deployments (in the Kubernetes sense), and then switching from
@@ -562,7 +562,7 @@ Then, you compare metrics between the current version and the canary
 that you just deployed. If the metrics are similar, you can proceed.
 If latency, error rates, or anything else looks wrong, you roll back.
 
-![Canary Deployment](figures/03-canary.png){ width=70% }
+![Canary Deployment](figures/03-canary.png){ width=95% }
 
 This technique, which would be fairly involved to set up, ends up
 being relatively straightforward thanks to Kubernetes' native

chapters/04-cicd-best-practices.md

@@ -158,11 +158,11 @@ While it's great to keep your entire pipeline fast, on many occasions you can ge
 
 Unit tests run the fastest, because they are isolated and usually don't touch the database. They define the business logic, and are the most numerous, as is commonly depicted in the "test pyramid" diagram:
 
-![Test pyramid](figures/04-test-pyramid.png){ width=70% }
+![Test pyramid](figures/04-test-pyramid.png){ width=95% }
 
 A failure in unit tests then is a signal of a fundamental problem, which makes running the remaining high-level and long-running tests irrelevant. For these reasons, projects with test suites that run for anything longer than a minute should prioritize unit tests in the CI pipeline.
 
-![Multi-stage testing](figures/04-multistage-testing.png){ width=70% }
+![Multi-stage testing](figures/04-multistage-testing.png){ width=95% }
 
 This strategy allows developers to get feedback on trivial errors in seconds. It also encourages all team members to understand the performance impact of individual tests as the code base grows.
 

chapters/05-tutorial.md

@@ -250,7 +250,7 @@ building, testing, and deploying.
 
 Our CI/CD workflow begins by building the Docker image:
 
-![CI Flow](./figures/05-flow-docker-build.png){ width=70% }
+![CI Flow](./figures/05-flow-docker-build.png){ width=95% }
 
   - **Pull**: get the latest image from the CI registry. This optional
     step decreases the build time.
@@ -274,7 +274,7 @@ load balancer as the rest of the pods. As a result, a set fraction of
 user traffic goes to the canary. For example, if we have nine stable
 pods and one canary pod, 10% of the users would get the canary release.
 
-![Canary Flow](./figures/05-flow-canary-deployment.png){ width=70% }
+![Canary Flow](./figures/05-flow-canary-deployment.png){ width=95% }
 
   - **Copy**: the image from the Semaphore registry to the production
     registry.