Merge pull request #169 from adambkaplan/fix-old-blog

fix: Restore Intro to Shipwright Part 1

Author: openshift-merge-bot[bot]

content/docs/blog/posts/2020-10-21-intro-shipwright-pt1/index.md

@@ -4,6 +4,8 @@ title: "Introducing Shipwright - Part 1"
 linkTitle: "Intro to Shipwright (Part 1)"
 description: "A framework for building container images on Kubernetes"
 author: "Adam Kaplan ([@adambkaplan](https://github.com/adambkaplan))"
+aliases:
+- /blog/2020/10/21/introducing-shipwright-part-1
 resources:
 - src: "**.{png}"
   title: "Figure #:counter"
@@ -12,10 +14,10 @@ resources:
 
 What is Shipwright? Which problems does this project try to solve?
 
-In [Part 1](/blog/2020/10/15/introducing-shipwright-part-1) of this series, we'll look back at the history of delivering software applications,
+In [Part 1](docs/blog/posts/2020-10-21-intro-shipwright-pt1/) of this series, we'll look back at the history of delivering software applications,
 and how that has changed in the age of Kubernetes and cloud-native development.
 
-In [Part 2](/blog/2020/11/30/introducing-shipwright-part-2) of this series, we'll introduce Shipwright and the Build APIs that make it simple to
+In [Part 2](docs/blog/posts/2020-11-30-intro-shipwright-pt2) of this series, we'll introduce Shipwright and the Build APIs that make it simple to
 build container images on Kubernetes.
 
 ## Delivering Your Applications - A History
@@ -31,4 +33,74 @@ laptops, and uploading the JAR to our client's SFTP site. After submitting a tic
 a change control review with our client's IT department, our software would be released during a
 scheduled maintenance window.
 
-![](deploy-java-vm)
+{{< figure
+  src="deploy-java-vm.png"
+  width="640px"
+  height="360px"
+>}}
+
+For engineers in larger enterprises, this experience should feel familiar. You may have used C#,
+C++, or were adventurous and testing Ruby on Rails. Perhaps instead of compiling the application
+yourself, a separate release team was responsible for building the application on secured
+infrastructure. Your releases may have undergone extensive acceptance testing in a staging
+environment before being promoted to production (and those practices may still continue today). If
+you were fortunate, some of the release tasks were automated by emerging continuous integration
+tools like Hudson and Jenkins.
+
+## Delivering on Docker and Kubernetes
+
+The emergence of [Docker/Moby](https://mobyproject.org/) and [Kubernetes](https://kubernetes.io/)
+changed the unit of delivery. With both of these platforms, developers package their software in
+container images rather than executables, JAR files, or script bundles. Moving to this method of 
+delivery was not a simple task, since many teams had to learn entirely new sets of skills to deploy
+their code.
+
+I first learned of Docker and Kubernetes at a startup I had joined. We used Kubernetes as a means
+to scale our back-end application and break apart our Python-based monolith. To test our
+applications, we built our container images locally with Docker, and ran clusters locally with
+minikube or used a dev cluster set up with our cloud provider. For acceptance testing and
+production releases, we used a third-party continuous integration service to assemble our code into
+a container image, push it to our private container registry (also hosted by our cloud provider),
+and use a set of deployment scripts to upgrade our applications in the respective environment.
+Along the way, we had to learn the intricacies of Docker, assembling our image via
+[Dockerfiles](https://docs.docker.com/engine/reference/builder/), and running Python inside a
+container.
+
+{{< figure
+  src="deploy-k8s-image.png"
+  width="640px"
+  height="360px"
+>}}
+
+What we could not do was build our applications directly on our Kubernetes clusters. At the time,
+the only way to build a container image on "vanilla" Kubernetes was to expose the cluster's Docker
+socket to a running container. Since docker ran as root, this presented a significant security
+risk - a malicious actor could use our build containers or service accounts to run arbitrary
+workloads on our clusters. Since our CI provider made it easy to build container images, and we
+implicitly trusted the security of their environments, we opted to use their service instead of
+running our container image builds on our clusters.
+
+## Creating Container Images Today
+
+Much has changed since the first release of Kubernetes with regard to building container images.
+There are now tools designed to build images from a Dockerfile inside a container, like
+[Kaniko](https://github.com/GoogleContainerTools/kaniko) and [Buildah](https://buildah.io/). Other
+tools like [Source-to-Image](https://github.com/openshift/source-to-image) and
+[Cloud-Native Buildpacks](https://buildpacks.io/) go a step further and build images directly from
+source code, without the need to write a Dockerfile. There are even image building tools optimized
+for specific programming languages, such as [Jib](https://github.com/GoogleContainerTools/jib).
+
+{{< figure
+  src="container-tools.png"
+  width="640px"
+  height="360px"
+>}}
+
+When it comes to delivering applications on Kubernetes, there is a wide variety of tooling and
+projects available. [Jenkins-X](https://jenkins-x.io/) and [Tekton](https://tekton.dev/) are two
+such projects that orchestrate continuous application delivery on Kubernetes. However, there is no
+standard way to produce container images on Kubernetes, nor is there a standard way for build tool
+authors to declare how to use their tool on Kubernetes.
+
+In Part 2 of this series, we aim to address these challenges by introducing Shipwright and the
+Build API.

content/docs/blog/posts/2020-11-30-intro-shipwright-pt2.md

@@ -9,15 +9,15 @@ draft: false
 
 What is Shipwright? Which problems does this project try to solve?
 
-In [Part 1](/blog/2020/10/21/introducing-shipwright-part-1/) of this series, we looked back at the history of delivering software applications,
+In [Part 1](docs/blog/posts/2020-10-21-intro-shipwright-pt1/) of this series, we looked back at the history of delivering software applications,
 and how that has changed in the age of Kubernetes and cloud-native development.
 
 In this post, we'll introduce Shipwright and the Build APIs that make it simple to
 build container images on Kubernetes.
 
 ## Recap - From Binaries to Images
 
-Recall in [Part 1](/blog/2020/10/21/introducing-shipwright-part-1/), developers who moved from 
+Recall in [Part 1](docs/blog/posts/2020-10-21-intro-shipwright-pt1/), developers who moved from 
 VM-based deployments to [Kubernetes](https://kubernetes.io/) needed to shift their unit of delivery
 from binaries to container images. Teams adopted various tools to accomplish this task, ranging
 from [Docker/Moby](https://mobyproject.org/) to [Cloud-Native Buildpacks](https://buildpacks.io/).