You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/modules/ROOT/pages/contributing/local-development.adoc
+19-2Lines changed: 19 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,8 +30,6 @@ This command will build and publish your actual Camel K development version to t
30
30
----
31
31
make install-k8s-global (default in camel-k namespace)
32
32
make install-k8s-ns (default in default namespace)
33
-
make install-openshift-global (default in camel-k namespace)
34
-
make install-openshift-ns (default in default namespace)
35
33
----
36
34
37
35
Those targets may use two variables, `NAMESPACE` and `REGISTRY` in order to let you specify the namespace where to install the operator and the container registry to use. For instance:
@@ -45,6 +43,25 @@ Will install a global operator in the `test` namespace with the registry located
45
43
46
44
In order to uninstall the local operator you can also run `make uninstall` (will keep CRDs) and `make uninstall-all` (will remove CRDs and consequently any running Integration). You can use variable `NAMESPACE` as well if the operator was installed in a namespace different than default.
47
45
46
+
=== CRC special requirement
47
+
48
+
You may need to test the operator on CRC. In such case you can login to the Openshift registry accessing its local interface:
With the steps above you should have available a local operator into CRC and proceed normally with the `make install-k8s-global` procedure.
62
+
63
+
NOTE: you will need to configure the IntegrationPlatform and the registry as required for Openshift and the operator Deployment may fail due to high amount of resources limit (which you can remove to let the operator start).
Copy file name to clipboardExpand all lines: docs/modules/ROOT/pages/installation/advanced/build-config.adoc
+1-3Lines changed: 1 addition & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,10 +20,8 @@ The most relevant are the `resource` and `limit` parameters which can be used to
20
20
21
21
The publish strategy is used to control the behavior of the creation of the container after a build. Basically it create a container image from the application built in the previous step and store as a container in the xref:installation/registry/registry.adoc[registry] configured.
22
22
23
-
The operator has 2 different strategy which you can adopt: Jib (default in plain Kubernetes profile) and S2I (default in Openshift profile).
23
+
The operator has one unique strategy which you can adopt: Jib. Alternatively you can provide your own publishing strategy (although this is not recommended).
24
24
25
25
https://cloud.google.com/java/getting-started/jib[Jib] is a technology that transform a Java project into a container image and is configurable directly in Maven.
26
26
27
-
https://access.redhat.com/documentation/es-es/openshift_container_platform/4.2/html/builds/understanding-image-builds#build-strategy-s2i_understanding-image-builds[S2I] is an efficient technology integrated in Openshift, reason why it is enabled by default in such a profile.
28
-
29
27
NOTE: you may define your own publishing technology by using xref:pipeline/pipeline.adoc[pipelines].
Another possibility is to upload to the cluster your entire list of push/pull secrets:
@@ -34,8 +34,8 @@ spec:
34
34
build:
35
35
registry:
36
36
address: <my-registry-address>
37
-
organization: <my-organization>
37
+
organization: <my-organization> (optional)
38
38
secret: <my-secret-credentials>
39
39
----
40
40
41
-
NOTE: make sure any credential contains the valid authentication servers: `docker.io` is used by **Jib**. Other publishing strategies may instead require to use a different endpoint, ie, `https://index.docker.io/v1/`.
41
+
NOTE: make sure any credential contains the valid authentication servers: for instance, `docker.io` is used by **Jib**.
Copy file name to clipboardExpand all lines: docs/modules/ROOT/pages/installation/registry/registry.adoc
+22-4Lines changed: 22 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,14 +8,26 @@ The Camel K operator is in charge to build a Camel application and to "container
8
8
9
9
For the reason above it's important that you provide a container registry which is accessible from both the operator Pod and the cluster internal mechanisms. However, a **default registry** is present in certain platforms such as _Minikube_, _Openshift_ or _Docker Desktop_.
10
10
11
-
For any other platform that do not provide a default container registry, then, a registry must be provided accordingly.
11
+
For any other platform that do not provide a default container registry, then, a container registry must be provided accordingly.
12
12
13
13
[[how-to-configure]]
14
14
== How to configure Camel K container registry
15
15
16
16
When running a production grade installation, you'll be probably using a private container registry which is accessible via authenticated method. The secret is something that will be https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-pod-that-uses-your-secret[included at deployment time] as `imagePullSecret` configuration.
17
17
18
-
As each registry may have a slightly different way of securing the access you can use the generic guidelines provided in xref:installation/registry/registry-secret.adoc[Secret registry configuration] and adjust accordingly. We expect that at the end of the process you have a public address (1) an _organization_ (2) and a _secret_ (3) values that will be used to configure the registry.
18
+
[[kubernetes-secret]]
19
+
=== Create a secret for your registry
20
+
21
+
The easiest way to create a Secret is to leverage the `kubectl` CLI:
NOTE: you must include `--docker-server docker.io` value also if you're using Docker Hub. The default value provided by `kubectl` won't.
29
+
30
+
As each registry may have a slightly different way of securing the access you can use the generic guidelines provided in and adjust accordingly (more information in the xref:installation/registry/registry-secret.adoc[Secret registry configuration] guide). We expect that at the end of the process you have a public address (1) an _organization_ (2) (optional, see details below) and a _secret_ (3) values that will be used to configure the registry.
19
31
20
32
You will need to create or edit any existing `IntegrationPlatform` custom resource with the values as expected in the `.spec.build.registry`.
21
33
@@ -31,13 +43,18 @@ spec:
31
43
build:
32
44
registry:
33
45
address: <my-registry-address>
34
-
organization: <my-organization>
46
+
organization: <my-organization> (optional)
35
47
secret: <my-secret-credentials>
36
48
----
37
49
38
50
The changes will be immediately reconciled and the operator will be able to push and pull resources in a secure manner.
39
51
40
-
[[configuring-registry]]
52
+
[[organization]]
53
+
=== Role of the organization parameter
54
+
55
+
The `organization` parameter is optional. When it's missing, the operator will use the namespace name to create an image within such organization name. When you're using an container registry you may be limited to store image in a given organization only. In this case, you must provide the name of such `organization` with this option.
56
+
57
+
[[requirements]]
41
58
== Container registry requirements
42
59
Each platform may have its default registry of choice. And each container registry may have a slight different configuration. Please, be aware that we won't be able to support all the available solutions.
43
60
@@ -57,6 +74,7 @@ We have some hints that can help you configuring on the most common platforms:
Openshift has an embedded container registry you can use to store the images produced by Camel K build process. The full details required to provide access to the registry are available in the https://docs.openshift.com/container-platform/4.17/registry/accessing-the-registry.html[Openshift registry documentation].
4
+
5
+
NOTE: before version 2.6, Camel K used S2I as a default publishing strategy against the embedded registry. Any upgrade from S2I to Jib should work out of the box.
6
+
7
+
== Service Account secret credentials
8
+
9
+
The first thing you need to do is to create an access token for the service account you want to use to pull/push images from the registry. We suggest to use the `camel-k-builder` Service Account which was created during the installation procedure and is normally used to perform "building" operations.
NOTE: `image-registry.openshift-image-registry.svc:5000` is the default internal route exposed by Openshift. You may need to use an alternative route according to the configuration of your cluster.
24
+
25
+
== Service account pull and push permissions
26
+
27
+
Before being able to pull and push containers images to the registry, you need to provide the proper privileges to access:
Now you should have all the authorizations required to pull and push containers to the image registry. In order to do that you will need to provide the Secret created above into your IntegrationPlatform configuration:
0 commit comments