Skip to content

[do not merge] Edits procedures in builds file #443

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

Closed
bfallonf wants to merge 1 commit into from
Closed

[do not merge] Edits procedures in builds file #443

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
89 changes: 47 additions & 42 deletions architecture/core_objects/builds.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ by pods that run a build.
supports Git.
<4> *strategy* describes which build type is invoked along with build type
specific details.
<5> *gitHub* triggers are Github-specific webhooks that specify which repository
<5> *github* triggers are GitHub-specific webhooks that specify which repository
changes, such as a new commit, should invoke a new build. This trigger is
specific to the GitHub API.
<6> *generic* triggers are similar to GitHub webhooks in that they invoke a new
Expand Down Expand Up @@ -143,13 +143,14 @@ with embedded build process logic, such as building RPMs or building base Docker
images.

[#using-docker-credentials-for-pushing-and-pulling-images]
== Using Docker Credentials for Pushing and Pulling Images
== Using Docker Credentials to Push and Pull Images

Supply the `.dockercfg` file with valid Docker Registry credentials in order to push the output image into a private Docker Registry or pull the
builder image from the private Docker Registry that requires authentication.
Supply the `.dockercfg` file with valid Docker Registry credentials in order to
push the output image into a private Docker Registry or pull the builder image
from the private Docker Registry that requires authentication.

The *_.dockercfg_* JSON file exists in your home directory by default and has
following format:
The *_.dockercfg_* JSON file is found in your home directory by default and has
the following format:

====

Expand All @@ -169,24 +170,22 @@ following format:

You can define multiple Docker registry entries in this file. Alternatively, you
can also add authentication entries to this file by running the `docker login`
command. The file will be created if it does not exist.

Kubernetes provides the
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/secrets.md[Secret]
resource, which is used to store your configuration and passwords. You must
first create the `*Secret*` before builds can use your *_.dockercfg_* file for
pushing the output image:
command. The file will be created if it does not exist. Kubernetes provides
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/secrets.md[Secrets],
which are used to store your configuration and passwords.
Copy link
Author

@bfallonf bfallonf Jun 4, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@soltysh If Kubernetes provides the secret, why are we creating one in the next step? Would it more accurate to say something like "Kubernetes has the ability to utilize secret..." then we go on to create the secret for Kubernetes to utilize?

Copy link

@soltysh soltysh Jun 5, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, by provides I've meant about the ability to create ones.


. Before builds can use your *_.dockercfg_* file for pushing the output image,
create the `*Secret*`:
+
====
----
$ osc create -f secret.json
----
====

The `*data*` field for the `*Secret*` object must contain the `*dockercfg*` key
with the value set to the base64-encoded content of the *_.dockercfg_* file. For
example:

. The `*data*` field in the `*Secret*` must contain the `*dockercfg*` value set
to the base64-encoded content of the *_.dockercfg_* file. For example:
+
Copy link
Author

@bfallonf bfallonf Jun 4, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This question might need to be reference in the SSH procedure as well, but is this missing a step? In the SSH procedure we use the base64 command to find a value to put in the config file. Should a similar step be here?

Copy link

@soltysh soltysh Jun 5, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it should simplify user experience.

====

----
Expand All @@ -204,10 +203,10 @@ example:
----
====

Once you have the `*Secret*` created, you can add a `PushSecret` field into the
`Output` section of the `BuildConfig` and set it to the name of the `*Secret*`
that you created, which in the above example is `*dockerhub*`:

. Add a `PushSecret` field to the `output` section of the `BuildConfig` and
set it to the name of the `*Secret*` created in step one. As in the above
example, the following uses `*dockerhub*`:
+
Copy link
Author

@bfallonf bfallonf Jun 4, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is straight-forward, and I can see the name in the above step too, but when and how is the name of the secret established? In the above step too?

Copy link

@soltysh soltysh Jun 5, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is this part of the secret.json file:

"metadata": {
    "name": "dockerhub"
  },

====
----
"parameters": {
Expand All @@ -223,9 +222,9 @@ that you created, which in the above example is `*dockerhub*`:
----
====

Pull the builder Docker image from a private Docker registry by specifying the
. Pull the Docker build image from a private Docker registry by specifying the
`PullSecret` field, which is part of the build strategy definition:

+
Copy link
Author

@bfallonf bfallonf Jun 4, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which file is this in? The buildconfig?

Copy link

@soltysh soltysh Jun 5, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is part of the BuildConfig specification, this part defines the strategy used during build.

====
----
{
Expand All @@ -246,7 +245,7 @@ Pull the builder Docker image from a private Docker registry by specifying the
====

[#using-private-repositories-for-builds]
== Using Private Repositories for Builds
== Accessing Private Repositories for Builds Using SSH

Supply valid credentials to build an application from a private repository.
Currently, only SSH key based authentication is supported. The repository keys
Expand All @@ -269,22 +268,31 @@ key will be used to access your private repository.

The
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/secrets.md[Secret]
resource is used to store your keys. Create the `*Secret*` first before using
the ssh key to access the private repository. The `*data*` field for the
`*Secret*` object must contain your private key with the value set to the
base64-encoded content of that file:
resource is used to store your keys.

. Create the `*Secret*` before using the ssh key to access the private
repository.
+
====
----
$ osc create -f secret.json
----
====

. The `*data*` field in the `*_secret.json_*` file must contain your private key
with the value set to the base64-encoded content of that file. Find the desired
value with the following command:
+
====

----
$ base64 -w 0 $HOME/.ssh/id_rsa
6yJodHRwc1ovL2zuZGV4LmRvY21lci5aby92MS8iOnsiYXV0aCI6ImJXWnZhblJwYXpwdVoybGxkR2d4TUE9PSIsImVtYWlsIj8ibWlAbWlmby5zayJ9fQ==
----
====

Copy the value returned from the above command and place it into the
`ssh-privatekey` field in `*_secret.json_*` file:

+
Then enter the value into the `ssh-privatekey` field in the `*_secret.json_*` file:
+
====

----
Expand All @@ -302,19 +310,19 @@ Copy the value returned from the above command and place it into the
----
====

Copy link
Author

@bfallonf bfallonf Jun 4, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the question in the Docker procedure above, I just want to clarify this is the correct procedure. We find the value using the base64 command, then enter it into the secret.json file. Correct?

Copy link

@soltysh soltysh Jun 5, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup.

Then, create the `*Secret*` from the *_secret.json_* file using the following
. Create the `*Secret*` from the *_secret.json_* file using the following
Copy link
Author

@bfallonf bfallonf Jun 4, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is another secret being created here?

Copy link

@soltysh soltysh Jun 5, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SourceSecrets are separate topic from DockerSecrets, thus we create another secret. You can use both, but we've decided to have each topic covered full path.

command:

+
====
----
$ osc create -f secret.json
----
====

Add a `SourceSecret` field into the `Source` section inside the `BuildConfig`
. Add a `SourceSecret` field into the `Source` section inside the `BuildConfig`
and set it to the name of the `*Secret*` that you created, in this case
`*scmsecret*`:
Copy link
Author

@bfallonf bfallonf Jun 4, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the Docker procedure above, when and how was the name of the secret established?

Copy link

@soltysh soltysh Jun 5, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above.


+
====

----
Expand All @@ -332,7 +340,7 @@ and set it to the name of the `*Secret*` that you created, in this case
},
"source": {
"git": {
"uri": "git@repository.com:user/app.git"
"uri": "git@repository.com:user/app.git" <1>
},
"sourceSecret": {
"name": "scmsecret"
Expand All @@ -350,9 +358,6 @@ and set it to the name of the `*Secret*` that you created, in this case
}
}
----
====

[NOTE]
====
The URL of private repository is usually in the form `git@example.com:username/repository`
<1> The URL of private repository, usually in the form
`git@example.com:username/repository`
====