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.

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

Changing build steps from initContainers to Containers #564

Merged
merged 6 commits into from
Mar 5, 2019

Conversation

nader-ziada
Copy link
Member

@nader-ziada nader-ziada commented Feb 28, 2019

Changes

  • Replace log-writer entrypoint with waiting entrypoint
  • Remove configmap for entrypoint image
  • Update docs to describe entrypoint function
  • Add support for getting remote image …
    • use service account in task
    • fallback to default service account
  • add vendor dependencies for k8schain

Fixes: #224

Co-authored by @bobcatfish

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

See the contribution guide
for more details.

Release Notes

The containers executing the Task steps are changed from using InitContainers to Containers in the TaskRun pod. This is achieved by wrapping each container by a custom binary entrypoint to manage the order of the steps. As such, it is always recommended to explicitly specify a command for a Task step. If a step's image is in a private registry, a ServiceAccount with ImagePullSecrets should be provided in the Task . 

@googlebot googlebot added the cla: yes Trying to make the CLA bot happy with ppl from different companies work on one commit label Feb 28, 2019
@knative-prow-robot knative-prow-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Feb 28, 2019
@nader-ziada nader-ziada force-pushed the realcontainers branch 3 times, most recently from 7d9546e to d3a0b6e Compare February 28, 2019 19:50
Copy link
Member

@imjasonh imjasonh left a comment

Choose a reason for hiding this comment

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

This PR is my favorite PR that I've ever seen, and I'm excited to see it's this close to finally happening! 🎉 Thanks @pivotal-nader-ziada!

Can you add a YAML test that ensures that a build with two steps has those steps execute sequentially? We used to just be able to trust init containers to do that for us, but now we need something to ensure it's working. Even something as simple as:

steps:
- image: busybox
  entrypoint: bash
  args: ['-c', 'sleep 3 && touch foo']
- image: busybox
  args: ['ls', 'foo']

This would fail if steps are swapped or if they're run concurrently due to a future bug.

@@ -3,4 +3,5 @@ baseImageOverrides:
github.com/knative/build-pipeline/cmd/creds-init: gcr.io/knative-nightly/github.com/knative/build/build-base:latest
github.com/knative/build-pipeline/cmd/git-init: gcr.io/knative-nightly/github.com/knative/build/build-base:latest
github.com/knative/build-pipeline/cmd/bash: busybox # image should have shell in $PATH
github.com/knative/build-pipeline/cmd/entrypoint: busybox # image should have shell in $PATH
Copy link
Member

Choose a reason for hiding this comment

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

What does this image need a shell for?

Copy link
Member Author

Choose a reason for hiding this comment

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

thinking about it now again I guess it doesn't really need a shell. Will try it again without this

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted to have a shell because we are using this same image for the step to copy the binary to the tools/entrypoint location

args: []string{"hello", "world"},
expectedArgs: []string{
"-wait_file", "",
"-post_file", "/tools/0",
Copy link
Member

Choose a reason for hiding this comment

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

We should put this in /builder/tools/, since it's not unreasonable to expect a user's process already uses a /tools directory. Namespacing things in /builder helps since we can just sort of "reserve" the whole directory.

Copy link
Member Author

Choose a reason for hiding this comment

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

used /tools because it was already there from the log writing entrypoint that got removed. Is builder created anyway, or just as part of a git resource?

Copy link
Member Author

Choose a reason for hiding this comment

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

moved tools to /builder/tools

@nader-ziada
Copy link
Member Author

@imjasonh sure, will create the yaml test. Thanks

@nader-ziada
Copy link
Member Author

the ko app recently with its latest version changed the path of where it puts the binary, which I something we need to know as part of running the entrypoint image
if you are trying this locally, please update your ko

go get -u github.com/google/go-containerregistry/cmd/ko

@nader-ziada
Copy link
Member Author

/test pull-knative-build-pipeline-integration-tests

Copy link
Collaborator

@bobcatfish bobcatfish left a comment

Choose a reason for hiding this comment

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

very exciting!! just a few nitpicks from me :D

overwritten with a custom binary that redirects the logs to a separate location
for aggregating the log output (this currently does nothing but is to support
future work, see [#107](https://github.com/knative/build-pipeline/issues/107)).
overwritten with a custom binary that ensures the containers within the `Task`pod
Copy link
Collaborator

Choose a reason for hiding this comment

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

space after Task

Copy link
Member Author

Choose a reason for hiding this comment

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

nice catch :)

args: ['-c', 'sleep 3 && touch foo']
- image: busybox
cmd: bash
args: ['-c', 'ls', 'foo']
Copy link
Collaborator

Choose a reason for hiding this comment

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

this is a total nitpick and feel free to ignore me, but id personally rather see this as an end to end test than an example. to me the distinction is:

  • examples: things ppl look at when they want to know how to do something
  • end to end tests: things ppl dont need to look at which test our actual machinery

In knative/build everything was a yaml test since we didnt have the distinction 🤷‍♀️

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, makes sense, will do that

Name: InitContainerName,
Image: *entrypointImage,
Command: []string{"/bin/sh"},
// based on the ko version, the binary could be in one of two different locations
Copy link
Collaborator

Choose a reason for hiding this comment

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

😅

var err error
step.Command, err = GetRemoteEntrypoint(cache, step.Image, kubeclient, build)
if err != nil {
logger.Errorf("**ALERT**: Error getting entry point image", err.Error())
Copy link
Collaborator

Choose a reason for hiding this comment

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

does this error mean:

  • the controller has a problem <-- this is what the message currently implies
  • the user may have made an error (problem with image, problem with credentials)

if it's more likely the second, i dont think we should log something at all - if we do, i think it should be a bit less urgent looking

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll remove the alert part of the message, but I think its useful to log something when we couldn't get the remote image, wdyt?

img, err := remote.Image(ref, remote.WithAuthFromKeychain(authn.DefaultKeychain))
// this will first try to authenticate using the k8schain,
// then fall back to the google keychain,
// then fall back to anonymous
Copy link
Collaborator

Choose a reason for hiding this comment

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

i think the docs are a bit light on how this works, could we add a bit more? (i think right now they just say you should provide a serviceaccount that has the right credentials, but this logic looks like it'll do a bit more)

Copy link
Member Author

Choose a reason for hiding this comment

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

will add more

with the binary and file(s) is mounted.

If the image is a private registry, the service account should include an
[ImagePullSecret](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
Copy link
Collaborator

Choose a reason for hiding this comment

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

🎉

taskSpec:
steps:
- image: busybox
cmd: bash

Choose a reason for hiding this comment

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

s/cmd:/command:/

Copy link
Member Author

Choose a reason for hiding this comment

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

thanks, will fix that

cmd: bash
args: ['-c', 'sleep 3 && touch foo']
- image: busybox
cmd: bash

Choose a reason for hiding this comment

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

s/cmd:/command:/

- Replace log-writer entrypoint with waiting entrypoint
- Remove configmap for entrypoint image
- Update docs to describe entrypoint function
- use service account in task
- fallback to default service account
- add vendor dependencies for k8schain

Signed-off-by: Nader Ziada <nziada@pivotal.io>
- based on the version of ko used, the binary could be in /ko-app or
in /ko-app/entrypoint
now with entrypoint, steps should specify the command in the command
field and not in the args
nader-ziada added a commit to nader-ziada/pipeline that referenced this pull request Mar 4, 2019
- add e2e test to ensure entrypoint runs in the specified order
- move entrypoint mount folder to /builder/tools since the /builder
folder is already used by other parts of the controller
- fix the taskrun order yaml
- add more docs about pulling images
@nader-ziada
Copy link
Member Author

addressed comments and rebased, ready for review

nader-ziada added a commit to nader-ziada/pipeline that referenced this pull request Mar 4, 2019
- add e2e test to ensure entrypoint runs in the specified order
- move entrypoint mount folder to /builder/tools since the /builder
folder is already used by other parts of the controller
- fix the taskrun order yaml
- add more docs about pulling images

Signed-off-by: Nader Ziada <nziada@pivotal.io>
@shashwathi
Copy link
Contributor

@pivotal-nader-ziada : In e2e yaml test logs one of the test is failing.

pull-private-image-run=SucceededFalse but should be succeededtrue

Primary problem is the e2e yaml script not catching the error 🤦‍♀️

nader-ziada added a commit to nader-ziada/pipeline that referenced this pull request Mar 4, 2019
- add e2e test to ensure entrypoint runs in the specified order
- move entrypoint mount folder to /builder/tools since the /builder
folder is already used by other parts of the controller
- fix the taskrun order yaml
- add more docs about pulling images

Signed-off-by: Nader Ziada <nziada@pivotal.io>
- add e2e test to ensure entrypoint runs in the specified order
- move entrypoint mount folder to /builder/tools since the /builder
folder is already used by other parts of the controller
- fix the taskrun order yaml
- add more docs about pulling images

Signed-off-by: Nader Ziada <nziada@pivotal.io>
@knative-metrics-robot
Copy link

The following is the coverage report on pkg/.
Say /test pull-knative-build-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/taskrun/entrypoint/entrypoint.go 80.8% 63.4% -17.4
pkg/reconciler/v1alpha1/taskrun/resources/pod.go 83.7% 83.5% -0.3
pkg/reconciler/v1alpha1/taskrun/taskrun.go 74.3% 76.5% 2.2

Copy link
Contributor

@shashwathi shashwathi left a comment

Choose a reason for hiding this comment

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

Awesome PR 👍 🎆 Great job @pivotal-nader-ziada

My only feedback is about relying more k8s chain auth lib to pull image secrets from configured SA name instead of entry point doing that. Rest looks good.

@knative-prow-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pivotal-nader-ziada, shashwathi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [pivotal-nader-ziada,shashwathi]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@nader-ziada
Copy link
Member Author

The yaml tests are fixed now, the service account was missing ImagePullSecrets

I0304 19:56:21.762] >> Waiting for tests to finish
I0304 19:56:25.535] >> Checking test results
I0304 19:56:27.456] >> All YAML tests passed

@shashwathi
Copy link
Contributor

/lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cla: yes Trying to make the CLA bot happy with ppl from different companies work on one commit lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants