InitContainer - inside Step

[2020testuser]

I want to change the permission of the mounted volume in InitContainer (inside Tekton Step).
Can this be done? I'm getting an error when I try to use InitContainers within Step.

I'm using the latest version of Tekton Pipeline. Could anyone please provide more info. on whether InitContainer can be used inside Tekton Step? If not, what are the alternatives?
Thanks in advance!

[dibyom]

Are you trying to add an initContainer inside your step? Can you not add a previous step that does the same thing that your initContainer does?

/kind question

[2020testuser]

@dibyom - Very sorry for the delay. Since, the tekton step runs as a kubernetes container , user doesn't have access to run certain initializations within the step. That's the reason planned to use InitContainers. Was looking for something similar to Initconainers in Tekton or how Initcontainers can be initiated in Kubernetes. Thanks!

[chanseokoh]

@2020testuser you can chain multiple steps. Take a look at the tar example in this section. You can find many other examples with multiple steps in the doc. So, I think you can just add a new "InitContainer"-like step before your main step?

[2020testuser]

@chanseokoh - I got the application successfully tested with gradle jib. Thanks for all your help.

Now , I'm testing with plain gradle (to do time comparison).
I'm testing with plain gradle (4.5 image). What happens is after gradle build (using :docker task), I need to push the built image which is in server host to the Docker repository. I have a secret created for my docker config in my Kubernetes namespace. Since, gradle 4.5 image uses gradle user, when I use docker push command to push to the registry , I'm getting 'Permission denied error' as I have the docker push command in the 'script' section of the gradle image step.

Note: I need to use the application code 'as is' to test gradle and so unable to use other docker related gradle task that builds the image and pushes to the repository. So, using plain docker command to push the created image to the docker repo.
Sorry for a new topic here. Thought you may have better ideas as you know what I have been doing because of the issue background. Thanks !

[chanseokoh]

Because docker push pushes an image stored in a local Docker daemon (local to the running container), I assume in an earlier step you did gradle jibDockerBuild to build and push an image to the Docker daemon, right? Then, how about creating an image tarball instead of building an image to a Docker daemon? That is,

1. Run gradle jibBuildTar. This will create an image as a tarball at <project root>/build/jib-image.tar. (You can configure the tarball name if you want.)
2. In the next step, push the image tarball using a simple CLI tool like crane. Check the crane push doc. Note crane can get registry credentials from ~/.docker/config.json.

[chanseokoh]

BTW, doing gradle jib is immensely more efficient (in terms of saving time, storage, and bandwidth) than doing gradle jibDockerBuild|jibBuildTar and then pushing the image later, because gradle jib can push only those bytes that are missing the target registry.

[2020testuser]

@chanseokoh - The Jib works fine and I will be using it.
I'm doing a comparison ( as a report) on build time in Jib and plain Gradle (without Jib and with :docker task ) to showcase jib and make it as standard.
That's the reason testing with plain Gradle.
In plain gradle, the gradle image runs as gradle user (sample code below). So, after building the image, I want to push the image to the company's docker repo. using docker push command. I tried with service account that includes the docker config as secret, tried with docker login etc. and no luck. Am I missing anything? Wondering why the docker login is not working (eventhough it is a right/cleaner approach). Any ideas? Thanks!
Note: The same script works fine if I run as root user( which I can't use becox of RBAC/security).
image: <my orh docker repo>/gradle:4.5 workingDir: /workspace script: | #!/bin/sh set -o errexit gradle --no-build-cache --gradle-user-home=/workspace/.gradle --recompile-scripts serviceapi:docker -x test / -Duser.home=/workspace docker tag serviceapi:latest <my org docker repo/imagename:tag> docker login <my org docker url> -u <id> -p <encrypted password> docker push <my org docker repo/imagename:tag>

[chanseokoh]

Even before thinking about a secret account, docker config and what not, there is a fundamental issue if you want to use Docker.

Basically, using Docker requires root. It is one of the dreaded requirements that people dislike but have to live with. You do need to have elevated privileges to be able to do docker push. At least the Docker daemon should run as root. (Not 100% sure but the Docker CLI might run as a non-root user if the user is in the privileged docker OS group. However, the Docker daemon should run as root, and the Docker CLI needs root privileges to be able to connect and use the daemon.)

I heard there is something called "rootless Docker" (experimental), but I am not sure if it really works.

[2020testuser]

@chanseokoh - Thanks! Could you please let me know whether having a step (say, step 2) after the gradle step (say step 1)? In that way , step 2 can use Kaniko (or some other mechanism like shared workspace) to pull the built image from step 1 and send as parameter to step 2. gradle user is not needed in step2 but as you mentioned is root usre still needed?
I'll also try to do some testing .

Thanks!

[chanseokoh]

you mentioned is root usre still needed?

If you have to run Docker commands like docker push yourself in a step, then basically, yes. But perhaps, now I am thinking you may not have to run docker push yourself. Please read through.

Disclaimer: I am not a Tekton expert, and what I say here may be out of date or not ideal.

Before I talk about pushing a Docker image from Tekton, I'd like to talk about general file and information sharing between steps. I believe there are multiple ways to achieve this. Maybe the simplest is to use the shared /workspace filesystem. This example creates a file /workspace/FOO in one step and the next step reads that file. Another way (I think) would be to mount your own volume. Not sure if Workspaces is another related thing. I also saw defining some kind of explicit input-output resource relation between steps, but I am not so sure.

However, I think Tekton has some degree of built-in support for handling Docker image output. This example in the Tutorial explains a Task fetching source code from a GitHub repository and building a Docker image from it.

The image resource specifies the repository to which the image built by the Task will be pushed:

The Image resource type represents an image in a remote registry.

It is usually used as a Task output for Tasks that build images. This allows the same Tasks to be used to generically push to any registry.

Note the same tutorial section also showcases an example where it uses Kaniko.

Hope this helps.

[2020testuser]

@chanseokoh - Thanks Much for providing more than one option ! Will try out these options.

[2020testuser]

@chanseokoh - Thanks!

[ghost]

I'm going to close this issue as it seems the original question has been largely resolved. Feel free to reopen if there's more to discuss / do here.