Introducing an Image Management Abstraction Layer
by Ricardo Maraschini
Hello there,
As some of you may be aware, I have been working part-time on a project
called Tagger [1]. Its goal is to provide an image
management abstraction layer for Kubernetes. Tagger tries to mimic (to some
extent) the behavior of OpenShift's Image
Streams but on a vanilla Kubernetes cluster. Among its features, I can list:
- Automatic deployment whenever a new image is pushed.
- Allow for easy rollback and roll forward among distinct versions
(generations) of the same container image (today’s “latest”
vs yesterday’s “latest”).
- Kubectl plugins for pushing and pulling images directly to the cluster
(an attempt to abstract the registry existence, currently
supports “podman” container storage).
- Integration with quay.io and docker.io webhooks.
I have recorded a brief presentation (~8min) on what Tagger can achieve
[2]. Now to the meat of this email: I have been thinking
about what the next step for the project is and it seems to me it might be
a good fit for tighter integration with shipwright as an
opt-in feature. Some points where I think Tagger could be beneficial when
used together with shipwright:
- Trigger new builds whenever a new Image is pushed.
- Should one’s build be triggered every time a new base image shows up?
We can cover it.
- Provide shipwright with a local container storage volume with all images
needed before a build
- This is an idea I have been thinking about: an init container that
pulls everything locally before the actual build takes place.
- Builds won't need to pull images as they will be all there.
- Capture the build output image and publish it.
- If there are deployments associated with the image why not trigger them?
I have gone a long way but I am still far from reaching the end of it. If
any of you think that this is an entertaining idea, please reach
out. I want to give this project a place where it can deliver value to
users. :-)
[1] https://github.com/ricardomaraschini/tagger
[2] https://youtu.be/HZZeFLooeUM
3 years
Community Meeting Minutes - April 12, 2021
by Adam Kaplan
Minutes:
- Parameters EP - needs more feedback related to direction (free form
parameters vs. 1st class APIs). The environment variables proposal from
@gabemontero <https://github.com/gabemontero> will be influenced by our
approach here.
- Twitter account - there is a growing need for credentials to be shared
among project maintainers/admins. This applies not just to our twitter
account, but things like credentials used in our private git test suite.
- Removing deprecated fields - we need to ensure that we can do this
safely for things that upgrade Shipwright. Example - do we ensure that
unknown fields are preserved in etcd? In addition, downstream consumers may
depend on current APIs, they need notice before fields are removed.
- k8s 1.20 bump revealed that some e2e/integration tests include kube
versions in their names. If possible, this should be switched to use
"latest"
- Removing PipelineResources - this is not being promoted out of Tekton
alpha. EP is up to discuss our path forward.
- Local source EP - a similar feature is being proposed in Tekton, with
a different technical approach. This is an area we can collaborate in. All
agree this is a feature Shipwright wants.
GitHub issue link: https://github.com/shipwright-io/build/issues/701
--
Adam Kaplan
He/Him
Principal Software Engineer
Red Hat <https://www.redhat.com>
100 E. Davie Street
adam.kaplan(a)redhat.com T: 1-919-754-4843
<https://www.redhat.com>
3 years
Shipwright Build v0.4.0 Now Available
by Adam Kaplan
I'm pleased to announce that Shipwright Build v0.4.0 is now available! A
special thank you is deserved to all the contributors to this release - it
is one of our biggest releases to date, laying the foundation for a lot of
important features in the future.
Shipwright Build v0.4.0 can be found on GitHub at
https://github.com/shipwright-io/build/releases/tag/v0.4.0.
This release includes several breaking changes and is incompatible with
previous versions of Shipwright Build.
*Upgrade Instructions*
1. Install v0.4.0 using the release YAML manifest:
$ kubectl apply -f
https://github.com/shipwright-io/build/releases/download/v0.4.0/release.yaml
2. Download existing `Build`, `BuildStrategy`, and `ClusterBuildStrategy`
objects from your cluster in YAML format.
3. For each object, change the `apiVersion` from `build.dev/v1alpha1` to `
shipwright.io/v1alpha1`. Remove any identifiers and creation timestamps
from the object's metadata.
4. Run `kubectl apply -f` against each manifest to re-create the relevant
object.
*Uninstalling v0.3.0*
Once the desired Shipwright Build objects have been migrated to the new api
group, you can remove v0.3.0 from your cluster:
1. Delete the `build-operator` namespace:
$ kubectl delete ns build-operator
2. (optional) Delete all `BuildRun`, `Build`, `BuildStrategy`, and
`ClusterBuildStrategy` objects in the build.dev api group on the cluster:
$ kubectl delete buildrun.build.dev --all --all-namespaces
$ kubectl delete build.build.dev --all --all-namespaces
$ kubectl delete buildstrategy.build.dev --all --all-namespaces
$ kubectl delete clusterbuildstrategy.build.dev --all
3. (optional) Delete the custom resource definitions for `BuildRun`,
`Build`, `BuildStrategy`, and `ClusterBuildStrategy` in the build.dev api
group:
$ kubectl delete crd buildruns.build.dev
$ kubectl delete crd builds.build.dev
$ kubectl delete crd buildstrategies.build.dev
$ kubectl delete crd clusterbuildstrategies.build.dev
Please reach out to the contributors on the mailing lists or Kubernetes
Slack (channel #shipwright) if you have any questions or issues with the
new release.
--
Adam Kaplan
He/Him
Principal Software Engineer
Red Hat <https://www.redhat.com>
100 E. Davie Street
adam.kaplan(a)redhat.com T: 1-919-754-4843
<https://www.redhat.com>
3 years