-
Notifications
You must be signed in to change notification settings - Fork 55
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
Considered using Kaniko? #46
Comments
Yep! Just haven't had time to dig into this yet. It may also be possible to use it to resolve #1. Some context here: concourse/docker-image-resource#190 (comment) |
I've used kaniko and ran into multiple issues where a |
@jmccann Can you disclose the Dockerfile that needed hacks? I havent experienced any of those incompatibilities. Using it for almost a year now on the daily for many images |
@f0o I don't have an example readily available as I've given up for a few months and would have to go back and dig into and/or try again. Also not sure I'm at liberty to share. But I will say personally I've ran into about 3 separate Dockerfiles I tried to convert to using kaniko that I ran into issues with. I've personally had about a 50% success rate. I've seen others run into issues as well. I will say majority of people seem to be able to use it without issue. But I'm worried that multiple times things that work completely fine with Unfortunately the cases I've ran into where there were issues with kaniko and not docker were not maybe "typical" builds. However, I wouldn't say they were complete weird edgecases either. But maybe not something that'd be easy to reproduce more generically quickly to share. I would just say if you decide to move that direction be very aware of if/when people start opening issues for failed builds. 😄 |
This adds 'image args', configurable with IMAGE_ARG_* - similar to BUILD_ARG_*, only the value points to an image tarball. The image tarball will be loaded and served by a local registry, and a reference to the image in the local registry will be provided as the build arg. To use this, you must modify your Dockerfile like so: ARG base_image=ubuntu FROM ${base_image} Then, when running oci-build-task, specify: params: IMAGE_ARG_base_image: ubuntu/image.tar This will remain forward compatible if we ever switch to Kaniko (#46), which would also require using build args as Kaniko image caching requires a full digest to be specified in FROM. fixes #1 closes #2 closes #3 closes #14 Signed-off-by: Alex Suraci <[email protected]>
? "Last I tried kaniko was several months ago" and "recent experience" from a single user and which are conflicting arguments IMO. I'm surprised that a single comment without any clear example on the issue seems to block the change forward kaniko. Personally I've been using it for 1-2 years without any issue in all Dockefile. Being able to build without elevated privileges is worth the change. |
I guess it could be considered conflicting 😆 I hope I'm not blocking (and don't think I am). I'm just giving my experience. |
Definitely isn't blocking - if it was this would be closed. The only thing blocking this is the number of hours in the day and the fairly dramatic code change it would imply, which makes the barrier to entry pretty high for me. Anyone could create an alternative Kaniko-flavored image builder though; there's no monopoly. |
I'm new to concourse and I already setup my build with kaniko without specifying a custom image, using the one from gcr.io. What is the added value of creating a custom one like this project on top of such a tool? |
@marcaurele could you share concourse build using kaniko container snippet here? |
I do in 2 steps:
---
# Kaniko build: `--force` is required on concourse for unknown reason, otherwise
# it does not detect it's inside a container.
platform: linux
image_resource:
type: registry-image
source:
repository: gcr.io/kaniko-project/executor
tag: debug
params:
BRANCH: dev
PUSH:
TAG_SUFFIX:
inputs:
- name: repo
- name: credentials
optional: true
run:
path: sh
args:
- -ecx
- |
CREDENTIALS_FILE=credentials/config.json
test -f $CREDENTIALS_FILE && cp $CREDENTIALS_FILE /kaniko/.docker/config.json || echo "Missing credentials file!"
FILE_SHORT_REF=repo/.git/short_ref
git_short_ref=$(test -f $FILE_SHORT_REF && cat $FILE_SHORT_REF || echo "dev")
FILE_REF=repo/.git/ref
git_ref=$(test -f $FILE_REF && cat $FILE_REF || echo "dev")
destination_flag=$(test -z $PUSH && echo "--no-push" || \
echo "--destination $REPOSITORY:$git_short_ref$TAG_SUFFIX --destination $REPOSITORY:latest$TAG_SUFFIX")
/kaniko/executor --force \
--build-arg "version=$git_ref" \
--single-snapshot \
--label org.opencontainers.image.version=$BRANCH \
--label org.opencontainers.image.revision=$git_ref \
--label org.opencontainers.image.created=$(date -Iseconds -u) \
--context repo/ \
--skip-unused-stages \
--target $IMAGE_TARGET \
$destination_flag |
Thanks @marcaurele! |
I think this ticket can be closed as kaniko will require a large effort1 to provide multi-arch build, therefore it's not a good option to follow. Footnotes |
Kaniko supports building images without requiring privileged mode.
https://github.com/GoogleContainerTools/kaniko
The text was updated successfully, but these errors were encountered: