Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Proofreading build.md #58 #59

Closed
wants to merge 1 commit into from
Closed

Proofreading build.md #58 #59

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions config.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title = "Shipwright"

enableRobotsTXT = true

# Hugo allows theme composition (and inheritance). The precedence is from left to right.
# Hugo enables theme composition (and inheritance). The precedence is from left to right.
theme = ["docsy"]

# Will give values to .Lastmod etc.
Expand Down Expand Up @@ -82,13 +82,13 @@ copyright = "The Shipwright Contributors"
# This menu appears only if you have at least one [params.versions] set.
version_menu = "Releases"

# Flag used in the "version-banner" partial to decide whether to display a
# Flag used in the "version-banner" partial to decide whether to display a
# banner on every page indicating that this is an archived version of the docs.
# Set this flag to "true" if you want to display the banner.
archived_version = false

# The version number for the version of the docs represented in this doc set.
# Used in the "version-banner" partial to display a version number for the
# Used in the "version-banner" partial to display a version number for the
# current doc set.
version = "0.0"

Expand Down Expand Up @@ -132,12 +132,12 @@ footer_about_disable = false
# add "hide_feedback: true" to the page's front matter.
[params.ui.feedback]
enable = true
# The responses that the user sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful).
# The responses that the reader sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful).
yes = 'Glad to hear it! Please <a href="https://github.com/USERNAME/REPOSITORY/issues/new">tell us how we can improve</a>.'
no = 'Sorry to hear that. Please <a href="https://github.com/USERNAME/REPOSITORY/issues/new">tell us how we can improve</a>.'

# Adds a reading time to the top of each doc.
# If you want this feature, but occasionally need to remove the Reading time from a single page,
# If you want this feature, but occasionally need to remove the Reading time from a single page,
# add "hide_readingtime: true" to the page's front matter
[params.ui.readingtime]
enable = false
Expand Down
28 changes: 14 additions & 14 deletions content/en/blog/posts/2020-11-30-intro-shipwright-pt2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,25 +17,25 @@ 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](/blog/2020/10/21/introducing-shipwright-part-1/), 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/).
New cloud-native applications like [Jenkins-X](https://jenkins-x.io/) and
[Tekton](https://tekton.dev/) have emerged to deliver these container images on Kubernetes.
[Jenkins](https://www.jenkins.io/) - the predecessor to Jenkins-X - has continued to play a
[Jenkins](https://www.jenkins.io/) - the predecessor to Jenkins-X - has continued to play a
prominent role in automating the building and testing of applications.

Building a container image on Kubernetes is not a simple feat. There are a wide variety of tools
available, some which require knowledge on how to write a Dockerfile, others which do not or are
tailored for specific programming languages. For CI/CD platforms like Tekton, setting up a build
tailored for specific programming languages. For CI/CD platforms like Tekton, setting up a build
pipeline requires extensive configuration and customization. These are burdens that are difficult
to overcome for many development teams.

## Shipwright Builds - A Framework for Building Images

With Shipwright, we want to create an open and flexible framework that allows teams to easily build
container images on Kubernetes. Much of the work has been inspired by OpenShift/okd, which provides
container images on Kubernetes. Much of the work has been inspired by OpenShift/okd, which provides
its own API for building images. At the heart of every build are the following core components:

1. Source code - the "what" you are trying to build
Expand All @@ -62,18 +62,18 @@ Developers who use docker are familiar with this process:

The Build API consists of four core Custom Resource Definitions (CRDs):

1. `BuildStrategy` and `ClusterBuildStrategy` - defines how to build an application for an image
1. `BuildStrategy` and `ClusterBuildStrategy` - defines how to build an application for an image
building tool.
2. `Build` - defines what to build, and where the application should be delivered.
3. `BuildRun` - invokes the build, telling the Kubernetes cluster when to build your application.

### BuildStrategy and ClusterBuildStrategy

`BuildStrategy` and `ClusterBuildStrategy` are related APIs to define how a given tool should be
`BuildStrategy` and `ClusterBuildStrategy` are related APIs to define how a given tool should be
used to assemble an application. They are distinguished by their scope - `BuildStrategy` objects
are namespace scoped, whereas `ClusterBuildStrategy` objects are cluster scoped.

The spec consists of a `buildSteps` object, which look and feel like Kubernetes `Container`
The spec consists of a `buildSteps` object, which look and feel like Kubernetes `Container`
specifications. Below is an example spec for Kaniko, which can build an image from a
Dockerfile within a container:

Expand Down Expand Up @@ -142,7 +142,7 @@ is possible.

### BuildRun

Each `BuildRun` object invokes a build on your cluster. You can think of these as a Kubernetes
Each `BuildRun` object invokes a build on your cluster. You can think of these as a Kubernetes
`Jobs` or Tekton `TaskRuns` - they represent a workload on your cluster, ultimately resulting in a
running `Pod`.

Expand All @@ -169,9 +169,9 @@ step:
1. `/tekton/home`
2. `/workspace`

Where do these directories come from? Shipwright is built on top of [Tekton](https://tekton.dev/),
taking advantage of its features to simpify CI/CD workloads. Among the things that Tekton provides
is a Linux user `$HOME` directory (`/tekton/home`) and a workspace where the application can be
Where do these directories come from? Shipwright is built on top of [Tekton](https://tekton.dev/),
taking advantage of its features to simplify CI/CD workloads. Among the things that Tekton provides
is a Linux user `$HOME` directory (`/tekton/home`) and a workspace where the application can be
assembled (`/workspace`).

## Try it!
Expand All @@ -182,9 +182,9 @@ Shipwright can be installed in one of two ways:
2. As an operator via [OperatorHub](https://operatorhub.io/operator/shipwright-operator).

If your cluster has [Operator Lifecycle Manager](https://olm.operatorframework.io/) installed,
option 2 is the recommened approach. OLM will take care of installing Tekton as well as Shipwright.
option 2 is the recommended approach. OLM will take care of installing Tekton as well as Shipwright.

The samples contain build strategies for container-based image build tools like
[Kaniko](https://github.com/GoogleContainerTools/kaniko), [Buildah](https://buildah.io/),
[Source-to-Image](https://github.com/openshift/source-to-image) and
[Kaniko](https://github.com/GoogleContainerTools/kaniko), [Buildah](https://buildah.io/),
[Source-to-Image](https://github.com/openshift/source-to-image) and
[Cloud-Native Buildpacks](https://buildpacks.io/).
Loading