Skip to content

Commit

Permalink
image and formatting fixups
Browse files Browse the repository at this point in the history
  • Loading branch information
@metahertz
metahertz committed Sep 19, 2017
1 parent 448aebe commit 126417e
Show file tree
Hide file tree
Showing 3 changed files with 36 additions and 42 deletions.
10 changes: 5 additions & 5 deletions labs/cicd-intro/1.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,11 +16,11 @@ Completion time: 30 minutes


# Recap
As discussed in Docker-101; Containers are a wonderful packaging and portability solution for your application. By building your code, it's dependancies and simple startup scripts into a container, you can gaurantee it will execute consistently wherever someone runs it. Be that on the developer machine, in the QA test environment, or in production;
As discussed in Docker-101; Containers are a wonderful packaging and portability solution for your application. By building your code, it's dependancies and simple startup scripts into a container, you can gaurantee it will execute consistently wherever someone runs it. Be that on the developer machine, in the QA test environment, or in production;

This consistency cannot be said of many other packaging formats for applications (such as ZIP, JAR, RPM's, DEB's). While 'baked' VM images offer the same consistency benefits, containers have a much smaller footprint owing to them being just userspace (sharing the single OS kernel) and therefore also 'boot' near instantly.

![](./assets/images/containerlifecycle.png)
![](/posts/files/cicd-intro/assets/images/containerlifecycle.png)



Expand All @@ -29,7 +29,7 @@ This consistency cannot be said of many other packaging formats for applications
## CI - Continuous Integration
Development projects often consists of many developers, all working on individual features and code. Eventually the individual work needs to be brought together and combined into a single code base. Individual developers should be testing their code as they work, but that code still needs re-verifying when it's part of the full codebase.

![](./assets/images/integration.png)
![](/posts/files/cicd-intro/assets/images/integration.png)

Even working solo on a project, there are advantages to knowing that each time you update your code "Something else" notices the change and re-run's all of your code tests against the changes, making your developer process look like this:

Expand Down Expand Up @@ -57,7 +57,7 @@ All our code, plus any dependancies and startup scripts are packaged into a cont

Because we have Automated CI, we can start to build a "pipeline", in which CI will automatically kick off the packaging of the software if the tests were passed.

![](./assets/images/packaging.png)
![](/posts/files/cicd-intro/assets/images/packaging.png)

Again, even in a solo developer scenario, not having to manually run `docker build .` followed by `docker tag` and `docker push` every time you change your code, is a considerable benefit.

Expand All @@ -66,7 +66,7 @@ Once new code has been packaged and placed somewhere accessible (such as a docke

If we choose to, the automation pipeline can do this automatically for each new code change, or potentially this goes through a manual "approval" step, it all depends on the developer or team configuring their CI/CD pipeline.

![](./assets/images/deployment.png)
![](/posts/files/cicd-intro/assets/images/deployment.png)


The deployment phase of CICD is the most affected by the rise of containers, deployment of software using automation used to involve spinning up new virtual machines, having the automation communicate with them using Puppet, ansible, or some other configuration management tool, then have that tool upgrade/install and setup the software and it's dependancies on the machines.
Expand Down
51 changes: 26 additions & 25 deletions labs/cicd-intro/2.md
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# The Tools of CI/CD
To build our CI/CD pipeline, we're going to need a few tools and services.

## 1. Git / Code repository
### 1. Git / Code repository
We need somewhere to check our code into for versioning.

Usually, this is github.com, github enterprise, gitlab, gogs, or some other git-based code repository system.
Expand All @@ -10,7 +10,7 @@ Code repository's can also alert other systems when a change is made (via a webh

We'll be using Gogs, a self hosted Git server for this lab.

## CI/CD Server
### 2. CI/CD Server
A CI/CD server allows us to piece together actions for our pipeline such as test code, package code, deploy code with simple "if, then, else" style logic.

Many tools exist in this area, with our favorite being Drone, as it allows all of the actions to be run in docker containers, keeping the CI/CD base system clean.
Expand All @@ -21,13 +21,16 @@ Jenkins was historically the leader in this space, the difference being that Jen

We'll be using Drone in this lab.

## A Container repository
### 3. A Container repository
Where do we put our packaged containers so that we can deploy them somewhere? Docker repositories come in public and private (self hosted) flavours, we'll be using an internal repository for simplicity, hosted on the drone CI/CD server.

## A 'Deployment Destination'
### 4. A 'Deployment Destination'
Where do we want our pipeline to deploy our new code, any container orchestrator can be configured on a per-codebase (per pipeline) basis, we'll be using Kubernetes as our deployment destination.

# Deployment 1/2: To the Sandbox!

![](/posts/files/cicd-intro/assets/images/sandboxbanner.png)

Setting up a kubernetes cluster, gogs server and drone installation would in itself be a learning lab longer than this one!

We care about using these tools to make a CI/CD system, not how they are installed, for that reason, our DEVNET sandbox team has built a CI/CD sandbox, with all the services we need pre-configured for our convenience.
Expand All @@ -54,7 +57,7 @@ Details and credentials will be included in the e-mail.

You will then have direct network access to all of the Sandbox services.

![](./assets/images/sandbox.png)
![](/posts/files/cicd-intro/assets/images/sandbox.png)

# Deployment 2/2: Hello World CI/CD
Our example setup is going to look like this.
Expand All @@ -63,12 +66,12 @@ We'll simulate the developers laptop/desktop on the 'DevBox', this has developer

Changes to our code get commited via git to our Gogs server, which in turn tells Drone CI of the change, drone tests, packages and finally deploys our code to our kubernetes cluster.

![](./assets/images/workflow.png)
![](/posts/files/cicd-intro/assets/images/workflow.png)

You may think that this is a lot of configuration, but drone actually get's all of it's instructions from a configurtation file stored *INSIDE* your code repository, that lets a single drone server handle completley different scenarios from many teams and repositories.
You may think that this is a lot of configuration, but drone actually get's all of it's instructions from a configuration file stored *INSIDE* your code repository, that lets a single drone server handle completley different scenarios from many teams and repositories.


## A. Our sample codebase
## A. Our sample codebase

We have a sample codebase to work with for this lab, lets download it to our 'DevBox';

Expand All @@ -80,9 +83,9 @@ SSH to the devbox, clone the git repository;
git clone https://github.com/CiscoDevNet/cicd_learninglab_demo.git
cd cicd_learninglab_demo
```

If we take a look around our codebase, we have;

```
[root@devbox cicd_learninglab_demo]# ls -la
total 20
Expand Down Expand Up @@ -124,7 +127,7 @@ pipeline:
insecure: true
tag: latest
```

Our Simple drone configuration is saying "check out any new code from the GIT repository at `drone:5000/cicd-helloworld` and use the Dockerfile within to create our docker image.

Upload this image to our docker repository at `drone:5000` and tag the image as version `latest`
Expand All @@ -140,7 +143,7 @@ Drone uses plugins, you'll notice in both the `publish:` and `deploy:` sections

You can see for the `deploy:` section, we are using the plugin `trxuk/kube`, this is a custom plugin hosted on a public docker repository. You can dig into how this plugin works if you wish by looking at the source here: [https://github.com/matjohn2/sbx_cicd/tree/master/kube]()

#B. Make it Real
## B. Make it Real
So drone will take the actions based on our `.drone.yml` when the code changes in the GIT repo, so lets push our codebase to our internal Sandbox git repo!

A repository has already been setup in `gogs` and tied to `drone` via a webhook (so drone knows when new commits are made to our codebase).
Expand All @@ -152,32 +155,32 @@ We add a new 'destination git server' to our codebase (also known as a git remot
[cicd_learninglab_demo]# git push cicd master
```

Drone will immediatley notice the push and start running the pipeline! We can see this via the drone UI, nativate in a web browser to:
Drone will immediatley notice the push and start running the pipeline! We can see this via the drone UI, nativate in a web browser to:
[http://10.10.20.25/test/cicd_example_repo]()

The drone login is *test/test*

![](./assets/images/drone1.png)
![](/posts/files/cicd-intro/assets/images/drone1.png)

Notice that drone gives this `build` a number (the first change drone has noticed to this repository) and has a section for each `plugin` in our `.drone.yml`; publish and deploy.

![](./assets/images/drone2.png)
![](/posts/files/cicd-intro/assets/images/drone2.png)

Once the build has finished, it will turn green if sucessful; Don't forget, the idea of CI/CD is to build, TEST and publish, most pipeline configurations would have a `publish:`, `test:` and `deploy:` section at the very least.

![](./assets/images/drone3.png)
![](/posts/files/cicd-intro/assets/images/drone3.png)

So our application has been packaged and deployed! Congratulations!

Let's see the output in the Kubernetes UI, available at: [http://10.10.20.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/workload?namespace=default]()

![](./assets/images/k8s1.png)
![](/posts/files/cicd-intro/assets/images/k8s1.png)

Here we can see our `deployment` created by Drone, if you click on the "Services" tab on the left, you can also see the IP address assigned to our deployment;

![](./assets/images/k8s2.png)
![](/posts/files/cicd-intro/assets/images/k8s2.png)

#C. Access our APP!
## C. Access our APP!
So we have a webserver, running in kubernetes with our HTML "app" code inside! Lets see it!

*Due to the current CICD sandbox setup, there is no route from your VPN client to the kubernetes workloads, so we'll have to see our app by SSH'ing to one of the servers in the Sandbox, this will be resolved and the instructions updated soon!*
Expand All @@ -191,7 +194,7 @@ ssh root@10.10.20.1

Then run the commandline HTTP browser, curl, to see our app; notice the IP for the app is the one from the "services" page in the kubernetes UI, yours may differ:

![](./assets/images/k8ssvcip.png)
![](/posts/files/cicd-intro/assets/images/k8ssvcip.png)

```
Last login: Tue Sep 19 07:41:59 2017 from devbox.abc.inc
Expand All @@ -206,10 +209,8 @@ Warm regards from the CICD Learning Lab demo app!
</html>
[root@netmaster ~]#
```
*EXCELLENT!* Our App is running and serving clients.

Now lets use CI/CD to automate another change!

# CI/CD - Making Changes!
## *EXCELLENT!*
Our App is running and serving clients.

## Change the APP
Now lets use CI/CD to automate another change!
17 changes: 5 additions & 12 deletions labs/cicd-intro/3.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ git push cicd master
```
This will kick off a new build in drone, notice that drone includes the git commit message from the change, in my case: "index text changes"

![](./assets/images/cichange1.png)
![](/posts/files/cicd-intro/assets/images/cichange1.png)

(Reminder, Drone UI is at: [http://10.10.20.25/test/cicd_example_repo/]()).

Expand All @@ -39,7 +39,7 @@ On our devbox, edit the `.drone.yml` file and replace the following lines:
tags: latest
tag: latest
```
with
with

```
tags: ${DRONE_BUILD_NUMBER}
Expand Down Expand Up @@ -80,15 +80,15 @@ git add and commit our drone changes, just like we did with `index.html`;
```

Going back to the drone UI, we can see the new build. By expanding the `publish` section in the UI, we can get a live feed of the commands being run; notice when we get to the point of uploading our new container image, it now has a version tag as a number, not just `latest`:
![](./assets/images/latest9.png)
![](/posts/files/cicd-intro/assets/images/latest9.png)

in my case, it's build `9`;
![](./assets/images/build9.png)
![](/posts/files/cicd-intro/assets/images/build9.png)

## SUCCESS!
Going back to our kubernetes UI, you will see from the "workloads" page that kubernetes has now noticed the change from deployment version `latest` to deployment version `9` (or another number in your case).

![](./assets/images/k8supdate.png)
![](/posts/files/cicd-intro/assets/images/k8supdate.png)

Checking our app again via curl from the kubernetes server, shows that with the new versioning, our new app content has finally been deployed!

Expand Down Expand Up @@ -123,10 +123,3 @@ Congratulations on building your first CI/CD pipeline with Docker, Drone and Git
Drone has a wide number of existing plugins for testing, packaging and deployment targets, see the documentation pages here:

[http://readme.drone.io/0.4/usage/overview/](http://readme.drone.io/0.4/usage/overview/)







0 comments on commit 126417e

Please sign in to comment.