Adding content to blog posts (#6)

NissesSenap · Aug 8, 2019 · 9e0ef9e · 9e0ef9e
1 parent 6b739c2
commit 9e0ef9e
Show file tree

Hide file tree

Showing 3 changed files with 100 additions and 71 deletions.
diff --git a/content/posts/azure_hugo_ci.md b/content/posts/azure_hugo_ci.md
@@ -12,23 +12,36 @@ description = "Building a Azure CI piepline for my Hugo blog"
 
 +++
 
+### Content
+
+- [Basic requirements](#basic-requirements)
+- [Tools](#tools)
+  - [Why do i pick Azure](#why-do-i-pick-azure)
+- [Detailed CI flow](#detailed-ci-flow)
+- [Setup Azure Pipelines](#setup-azure-pipelines)
+  - [CI](#ci)
+  - [Prepare the CD](#prepare-the-cd)
+    - [GitHub deploy keys](#github-deploy-keys)
+    - [Azure secret file](#azure-secret-file)
+  - [CD](#cd)
+
 ## Basic requirements
 
-* Trigger CI system at PR (pull request)
-* Give feedback to the user that the PR have passed
-* When I merge the pull, automatically publish my updated blog.
+- Trigger CI system at PR (pull request)
+- Give feedback to the user that the PR have passed
+- When I merge the pull, automatically publish my updated blog.
 
 The last one is already solved thanks to that i use GitHub static page to share my homepage.
 
 ## Tools
 
 My plan is to use the following tools:
 
-* Azure Pipelines
-* GitHub
-* [hub][hub_link]
-* Hugo
-* [Yaspeller][yaspeller_git] (to help me with my crappy spelling)
+- Azure Pipelines
+- GitHub
+- [hub][hub_link]
+- Hugo
+- [Yaspeller][yaspeller_git] (to help me with my crappy spelling)
 
 The reason why I chose Hugo as a static page generator is that I don't want to use Jekyll (don't like ruby) and it feels like a much more modern any way.
 I have worked with Gerrit and played with Gitlab, and Bitbucket and they all work just fine but most people use GitHub today and I want to use something that I most likely will use for my source-control in the future.
@@ -38,37 +51,37 @@ I have worked with Gerrit and played with Gitlab, and Bitbucket and they all wor
 Today we have many many options for CI/CD systems that is integrated with [GitHub][github_ci].
 I won't go through my reason why I thought X was better then Y but for me had the following main options:
 
-* TravisCI
-* CircleCI
-* Azure Pipelines
-* Google Cloud Build
-* Codefresh
+- TravisCI
+- CircleCI
+- Azure Pipelines
+- Google Cloud Build
+- Codefresh
 
 TravisCI was among the early CI systems that was enabled for free to open-source projects. I have contributed to a number of puppet modules that used TravisCI and it all worked great.
 But i would like to use something else, so it's not really an option for me.
 So in enters the rest of the options.
 
 In the end I choose **Azure Pipelines**, the main reasons:
 
-* They have great documentation overall.
-* If the documentation is bad they have it all open on GitHub and you can create a issue or a pull-request to fix it. Something other cloud providers is missing.
-* It's one of the big three cloud company's so it's a big chance of using this knowledge in the future.
-* I can use Terraform or other IAC solutions to create my CI system (something I will explore in the future).
+- They have great documentation overall.
+- If the documentation is bad they have it all open on GitHub and you can create a issue or a pull-request to fix it. Something other cloud providers is missing.
+- It's one of the big three cloud company's so it's a big chance of using this knowledge in the future.
+- I can use Terraform or other IAC solutions to create my CI system (something I will explore in the future).
 
 ## Detailed CI flow
 
 Even though I'm alone on this project I need to define some WoW (Way Of Working), or at least if i want to be able to run automated CI systems and get feedback from my pushes. It's kind of to late to run a spelling check if I just push the code directly to the repo.
 
 My current plan looks like this:
 
-* User create blog branch
-* Write new blog entry
-* Push the blog branch to the repo
-* Create a GitHub pull-request
-* Start the CI
-* If CI passes report back to GitHub as a message in the pull-request
-* Merge the PR
-* Azure Pipeline triggers a build of Hugo to the /docs folder and pushes the changes directly to the master branch
+- User create blog branch
+- Write new blog entry
+- Push the blog branch to the repo
+- Create a GitHub pull-request
+- Start the CI
+- If CI passes report back to GitHub as a message in the pull-request
+- Merge the PR
+- Azure Pipeline triggers a build of Hugo to the /docs folder and pushes the changes directly to the master branch
 
 ## Setup Azure Pipelines
 
@@ -102,11 +115,11 @@ steps:
 
 The yaml file does the following:
 
-* Only trigger when I push stuff to blog branch
-* Define which os and node type to use
-* Use a built in Azure function and get's node
-* Install all npm dependencies
-* Run the spellchecker
+- Only trigger when I push stuff to blog branch
+- Define which os and node type to use
+- Use a built in Azure function and get's node
+- Install all npm dependencies
+- Run the spellchecker
 
 Go to Azure DevOps -> New Build Pipeline (under the current UI you will find it under the +) -> Existing Azure Pipelines YAML file
 {{< figure src="/img/blog/azure_hugo_ci/add_pipeline.png" width="100%">}}
@@ -118,7 +131,7 @@ The CI job should now trigger on any PR from the blog branch.
 
 During the CD stage of the tipeline we want to be able to push a commit to GitHub.
 
-#### GitHub deploykeys
+#### GitHub deploy keys
 
 First we need to add an GitHub [deploykey][github_deploykeys].
 
@@ -196,16 +209,16 @@ steps:
 I have taken most of this from a [Microsoft blog][azure_git_push].
 The deployment job will do the following
 
-* Only trigger on a merge to master, never on a PR
-* Set 2 variables for reusability
-* Download Hugo and chmod it, **NOTE** how to call the variables
-* Add my submodule, build the page to the docs folder
-* Add the changes to a commit
-* Download the secure file, it's reachable using environment variables.
-* Create the .ssh folder, add the private ssh-key
-* Add GitHub as a known host
-* Push to the master branch
-* Be extra sure we don't create a infinite loop.
+- Only trigger on a merge to master, never on a PR
+- Set 2 variables for reusability
+- Download Hugo and chmod it, **NOTE** how to call the variables
+- Add my submodule, build the page to the docs folder
+- Add the changes to a commit
+- Download the secure file, it's reachable using environment variables.
+- Create the .ssh folder, add the private ssh-key
+- Add GitHub as a known host
+- Push to the master branch
+- Be extra sure we don't create a infinite loop.
 
 Now you should be able to run your own static webpage using GitHub for hosting, Hugo as generator and Azure Pipeline for CI/CD.
 

diff --git a/content/posts/first.md b/content/posts/first.md
@@ -5,12 +5,17 @@ draft = false
 showpagemeta = true
 showcomments = true
 slug = ""
-categories = ["about"]
+categories = ["About"]
 title = "First"
 description = "First"
-
 +++
 
+### Content
+
+- [Hello Internet](#hello-internet)
+- [What I have done](#what-i-have-done)
+- [What will happen in the future](#what-will-happen-in-the-future)
+
 ## Hello Internet
 
 So It's time for me to get a blog.
@@ -30,12 +35,12 @@ I started my work at a small IT company in Gothenburg called Zetup now named [No
 
 Until then I worked allot with:
 
-* Linux
-* Infrastructure As Code (IAC)
-* Monitoring
-* Python
-* HPC
-* CI/CD
+- Linux
+- Infrastructure As Code (IAC)
+- Monitoring
+- Python
+- HPC
+- CI/CD
 
 But in 2018 i joined [Alten](https://www.alten.se/) and started working more as a devops engineer as a consultant at Ericsson in an RND project called [CVC][cvc_link] helping out to send data from cars to the cloud.
 
@@ -52,11 +57,11 @@ After the summer of 2019 I'm joining [RedHat](https://www.redhat.com/) (IBM depe
 
 In the future I will most likely focus allot on:
 
-* Kubernetes
-* Openshift
-* cloud
-* CI/CD
-* IAC (Infrastructure As Code)
-* Linux
+- Kubernetes
+- Openshift
+- cloud
+- CI/CD
+- IAC (Infrastructure As Code)
+- Linux
 
 [cvc_link]: https://www.ericsson.com/en/internet-of-things/automotive/connected-vehicle-cloud
diff --git a/content/posts/iac_blog_part1.md b/content/posts/iac_blog_part1.md
@@ -9,9 +9,20 @@ categories = ["IT"]
 tags = ["IAC", "Terraform", "Godaddy"]
 title = "Infrastructure As Code Blog part 1 Godaddy with Terraform"
 description = "My first blog entry explaning how I use Terraform to handle Godaddy and the rest of my infrastructure"
-
 +++
 
+### Content
+
+- [Background](#background)
+- [Why Terraform](#why-terraform)
+  - [Requirements](#requirements)
+  - [IAC options](#iac-options)
+    - [Mutable Infrastructure vs Immutable](#mutable-infrastructure-vs-immutable)
+- [Godaddy Terraform](#godaddy-terraform)
+  - [Setting up Godaddy API key](#setting-up-godaddy-api-key)
+  - [Download the current config](#download-the-current-config)
+- [Future](#future)
+
 ## Background
 
 As you know if you have read my [last blog entry ]({{< ref "/posts/azure_hugo_ci.md" >}}) I use GitHub to host my static page and Azure Pipeline for CI/CD.
@@ -25,26 +36,26 @@ I have the following needs:
 
 ### Requirements
 
-* Support multiple SaaS/PaaS and most of it's features
-* Broad support amongst the community
-* Be fast to update if the SaaS/PaaS changes API
-* Easy to extend with scripts or other tools
-* Easy to get started
-* From basic to advanced
-* Good documentation
-* Open-source
+- Support multiple SaaS/PaaS and most of it's features
+- Broad support amongst the community
+- Be fast to update if the SaaS/PaaS changes API
+- Easy to extend with scripts or other tools
+- Easy to get started
+- From basic to advanced
+- Good documentation
+- Open-source
 
 ### IAC options
 
 Bellow is the IAC options that i feel viable.
 
-* Terraform
-* Ansible
-* Puppet
-* Chef
-* SaltStack
-* PaaS/SaaS own json/yaml or API
-* Python lib
+- Terraform
+- Ansible
+- Puppet
+- Chef
+- SaltStack
+- PaaS/SaaS own json/yaml or API
+- Python lib
 
 There are many more options then these but above you can see some of the old and new tools.