Wiki source code of Rancher 2

Version 26.1 by Diana Strebkova on 2026/04/20 09:19

Manage
- Copy
Actions
- Export
- Print Preview
Viewers
- Source
- Children
- Content
- Comments
- Likes

version	line-number	content
1.1	1	Rancher is a Kubernetes management tool to deploy and run clusters anywhere and on any provider.
	2
	3	The following page can only cover some special topics. Please read the [[official Rancher documentation >>url:https://ranchermanager.docs.rancher.com/\|\|rel="nofollow" shape="rect" class="external-link"]] to learn more about Rancher 2 and how to perform container management.
	4
	5	{{toc/}}
	6
	7	= (% style="letter-spacing:-0.01em" %)Role mapping(%%) =
	8
	9	No special permissions are assigned to Portal Admins. Currently, the only users with elevated permissions are users with //at least one// Project Admin role. For more info check out the [[Roles>>url:https://prd.sdc.t-systems.net/confluence/display/SDCLOUD/How+to+use+Rancher+2#HowtouseRancher2-Roles\|\|shape="rect"]] chapter.
	10
	11	(% class="table-bordered" style="width:100.0%" %)
	12	(% class="active" %)\|=(% colspan="1" style="text-align: left;" %)(((
	13	Project Role
	14	)))\|=(% colspan="1" style="text-align: left;" %)(((
	15	Rancher 2 Global Role
	16	)))\|=(% colspan="1" style="text-align: left;" %)(((
	17	Description
	18	)))
	19	\|(% style="text-align:left" %)(((
	20	Admin
	21	)))\|(% style="text-align:left" %)(((
	22	Standard User
	23	)))\|(% colspan="1" style="text-align:left" %)(((
	24	These users can create new clusters and use them. Standard users can also assign permissions for their clusters to other users.
	25	)))
	26	\|(% style="text-align:left" %)(((
	27	Master
	28	)))\|(% rowspan="3" style="text-align:left" %)(((
	29	User-Base
	30	)))\|(% rowspan="3" style="text-align:left" %)(((
	31	User-Base users have login-access only. But they can be added to clusters and namespaces.
	32	)))
	33	\|(% style="text-align:left" %)(((
	34	Developer
	35	)))
	36	\|(% colspan="1" style="text-align:left" %)(((
	37	Viewer
	38	)))
	39
	40	= (% style="letter-spacing:-0.01em" %)Login to Rancher(%%) =
	41
	42	As a first step, go to the Projects page in the DevOps Portal, then click on Rancher2 in the Tools column of one of your projects:
	43
	44	(% class="confluence-embedded-file-wrapper confluence-embedded-manual-size" %)[[image:attach:Screenshot 2023-03-16 at 18.38.02.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="228" width="900"]]
	45
	46	Then login to Rancher using the Keycloak option.
	47
	48	[[image:attach:MicrosoftTeams-image (2).png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="453" width="900"]]
	49
	50	Click on the "Log in with Keycloak" button as shown in the above screenshot.
	51
	52	After you logged in, the welcome page will look different depending on the level of access you have.
	53
	54	These are the two options:
	55
	56	1. If you have at least one Project Admin Role you get Standard User global permissions in Rancher. This will also show the "Import Existing" and "Create" button (for adding a cluster)// //as seen in the screenshot below:
	57	[[image:attach:MicrosoftTeams-image (3).png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="371" width="1000"]]
	58
	59	1. If you have no Project Admin Role, you get User-Base global permissions in Rancher. This means you cannot add new clusters. You will only see clusters for which somebody else has assigned you some permissions. The screenshot below shows how the welcome screen will look like:
	60	[[image:attach:MicrosoftTeams-image (4).png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" width="1000"]]
	61
	62	= Roles =
	63
	64	== Global Roles ==
	65
	66	As mentioned, users will be a member of one of the following two Global Roles which contain Global Permissions.
	67
	68	(% class="table-bordered" %)
	69	(% class="active" %)\|=(% style="text-align: left;" %)(((
	70	Display Name
	71	)))\|=(% style="text-align: left;" %)(((
	72	Name
	73	)))\|=(% style="text-align: left;" %)(((
	74	Permissions
	75	)))
	76	\|(% style="text-align:left" %)(((
	77	User-Base
	78	)))\|(% style="text-align:left" %)(((
	79	user-base
	80	)))\|(% style="text-align:left" %)(((
	81	* View/edit own preferences
	82	* Create/manage personal API key
	83	* View Global Settings (all sections)
	84	)))
	85	\|(% colspan="1" style="text-align:left" %)(((
	86	Standard User
	87	)))\|(% colspan="1" style="text-align:left" %)(((
	88	user
	89	)))\|(% colspan="1" style="text-align:left" %)(((
	90	* View/edit own preferences
	91	* Create/manage personal API key
	92	* View Global Settings (all sections)
	93	* Create clusters (import or create)
	94	* Cluster Management - See and manage own clusters
	95	* Create Cloud Credentials
	96	* View Cluster/Node drivers (Edit options are displayed but are not effective)
	97	* Create new Cluster/Node drivers
	98	* View PSP (Create/Edit options are displayed but are not effective)
	99	* View and Create PSA
	100	* View and Create RKE1 Node Templates
	101	* View RKE1 cluster templates (Add option is displayed but not effective)
	102	* View chart repo templates (relevance not clear)
	103	)))
	104
	105	For more information regarding roles and permissions for Rancher 2 please access the following link: [[https:~~/~~/ranchermanager.docs.rancher.com/>>url:https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions\|\|shape="rect"]]
	106
	107	== Cluster and Project Roles ==
	108
	109	Global roles are assigned based on the project role in the DevOps portal. In addition, roles at cluster or "project" level can be assigned, too. These roles are assigned within the Rancher UI and are not derived from any role in the DevOps portal.
	110
	111	{{info}}
	112	The term "project" within Rancher has a different meaning than used in the DevOps portal. Within Rancher, a project is a collection of namespaces with some configuration, including roles for specific users.
	113	{{/info}}
	114
	115	=== Cluster Roles ===
	116
	117	Cluster roles define permissions for individual users for a specific cluster, see this [[Link>>url:https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles#cluster-roles\|\|shape="rect"]] for further information from Rancher.
	118
	119	{{info}}
	120	Cluster roles can only be granted by the cluster owner who created or imported the cluster.
	121	{{/info}}
	122
	123	If roles shall be assigned to created or imported clusters, then follow this procedure:
	124
	125	1. Go to the Rancher homepage, where you see the list of managed clusters
	126	1. Click on the "Manage" button, the Cluster Management page is opened
	127	1. Click on the 3 dots on the right side of the line with the intended cluster → Click on "Edit config"
	128	1. Extend "Member Roles" and Click on "Add Member".
	129	[[image:attach:image-2023-4-25_11-2-51.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="254" width="646"]]
	130	1. Start typing the full name of the user. There should be a suggestion displayed. Click on it.
	131	1. In the role field, choose one of the built-in roles, see this [[Link>>url:https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles#cluster-roles\|\|shape="rect"]] for the description of permissions per role.
	132	1. Click on Save at the bottom of the page.
	133
	134	=== Project Roles ===
	135
	136	Within a cluster, roles can be assigned for individual Rancher projects. This allows a more granular permission assignment within a cluster. See this [[Link>>url:https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles#project-roles\|\|shape="rect"]] for further information.
	137
	138	{{info}}
	139	Project roles can only be granted by a user with a sufficient role within the cluster.
	140	{{/info}}
	141
	142	Follow this instruction to assign project roles to individual users:
	143
	144	1. In Rancher UI, switch to the cluster in which a project role shall be assigned.
	145	1. In the menu on the left side, click on Cluster/Projects+Namespaces.
	146	1. Switch to "Group by Project" presentation
	147	[[image:attach:image-2023-4-25_11-13-6.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="113" width="934"]]
	148	1. Search and find the project, for which you want to assign roles
	149	1. In the line of this project (not the line with a namespace), click on the 3 dots on the right side → Click on Edit Config
	150	1. Click on the Add (Members) button
	151	[[image:attach:image-2023-4-25_11-16-29.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" width="400"]]
	152	1. Start typing the full name of the user in the Select Member Field. There should be a suggestion displayed. Click on the entry with the full name (Local)
	153	1. In the Project Permission field, select the intended role, see this [[Link>>url:https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles#project-roles\|\|shape="rect"]] for further information.
	154	1. Click on "Add".
	155	1. Click on "Save" at the bottom of the page when all intended users have been are added.
	156
	157	= Helm charts =
	158
1.2	159	== Add public helm chart ==
1.1	160
	161	In this section, we describe (% style="color:#172b4d" %)how to add public helm charts like the one of DevOps-as-a-Service to a cluster to allow manual deployments.
	162
	163	(% id="HCreateAppRepositoryinRancher" class="p1" %)
	164	=== Create Chart Repository in Rancher ===
	165
	166	(% class="p1" %)
	167	In Rancher UI, switch to the intended cluster and go to Apps/Repositories using the left side menu.
	168	[[image:attach:Screenshot 2023-04-25 at 13.11.48.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="400" width="209"]]
	169
	170	(% class="p1" %)
	171	Create a new Repository by clicking the Create button.
	172
	173	(% class="p1" %)
	174	[[image:attach:Screenshot 2023-04-25 at 13.30.33.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="127" width="1100"]]
	175
10.3	176	To add public oci-repository, navigate to repository create button and click it. For target, use OCI Repository like shown below:
2.2	177
4.2	178	[[image:1765207154466-828.png\|\|height="298" width="821"]]
2.2	179
	180	In the "Repository: Create" dialog, simply fill in the following fields. Authentication is not required.
	181
	182	(% class="wrapped" %)
	183	\|=(((
	184	Field
	185	)))\|=(((
	186	Value
	187	)))
	188	\|=(((
	189	Name
	190	)))\|(((
4.5	191	devopsaas-jenkins-auto-agent
2.2	192	)))
	193	\|=(((
	194	Description
	195	)))\|(((
	196	Public Helm charts as documented at [[https:~~/~~/docs.devops.t-systems.net>>url:https://docs.devops.t-systems.net\|\|shape="rect"]]
	197	)))
	198	\|=(((
	199	Index URL
	200	)))\|(((
10.5	201	oci:~/~/registry.sdc.t-systems.net/devopsaas-helm/<chartname>, for example:
4.3	202
24.1	203	oci:~/~/registry.sdc.t-systems.net/devopsaas-helm/jenkins-auto-agent
10.3	204
20.1	205	{{box}}
	206	Take into account, that all internal harbor repositories with helm charts have PKEY-helm naming convention, adding repo with both docker images and helm charts is not supported in rancher.
	207	{{/box}}
2.2	208	)))
	209
3.2	210	{{info}}
10.6	211	Now all internal helm charts are stored in harbor folders with -helm suffix. Adding the whole public project doesn't work natively anymore, so each separate chart should be added as a separate repo. //If you have a need in adding the whole project with many repositories, please contact support for finding a possible solution.//
3.2	212	{{/info}}
2.2	213
1.1	214	=== Deploy Helm charts ===
	215
	216	Now go to Apps>Charts and filter if necessary for the devops-as-a-service Helm chart repository. Like shown below, a list of available charts is displayed. Simply click on one of the tiles to deploy them to your cluster.
	217
	218	Please note that the jenkins-lib charts are only generated for testing purposes. It doesn't make sense to deploy them. Your Jenkins is automatically retrieving the Jenkinslib directly using [[Git>>url:https://prd.sdc.t-systems.net/bitbucket/projects/DEVOPSAAS/repos/sdcloud-caas-jenkins-libs/browse\|\|shape="rect"]].
	219
	220	[[image:attach:image-2023-5-19_16-1-52.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" width="1100"]]
	221
	222	== Add private chart repository ==
	223
10.7	224	=== Create a robot account in Harbor ===
1.1	225
	226	To add project specific helm charts to Rancher, a Harbor robot account is needed, that is able to read helm charts and pull repositories. If you don't have such an account yet, please follow the instructions given in the [[Create Robot Account section of the Harbor documentation>>doc:Harbor.Harbor 2\.7 Robot Accounts.WebHome\|\|anchor="create_robot_account"]] and make sure to grant at least the following permissions:
	227
24.3	228	* Read Artifact
1.1	229	* Pull Repository
	230
	231	(% id="HCreateAppRepositoryinRancher-1" class="p1" %)
	232	=== Create App Repository in Rancher ===
	233
	234	(% class="p1" %)
	235	In Rancher UI, switch to the intended cluster and go to Apps/Repositories using the left side menu.
10.7	236
1.1	237	[[image:attach:Screenshot 2023-04-25 at 13.11.48.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="400" width="209"]]
	238
	239	(% class="p1" %)
	240	Create a new Repository by pressing the Create button.
	241
20.1	242	(% class="p1" id="HTarget:http28s29URL-1" %)
19.1	243	[[image:attach:Screenshot 2023-04-25 at 13.30.33.png\|\|data-xwiki-image-style-border="true" queryparams="effects=drop-shadow" height="127" width="1100"]]
8.1	244
10.2	245	(% id="HTarget:http28s29URL-1" class="p1" %)
24.3	246	==== ====
5.2	247
5.4	248	{{info}}
10.11	249	Now all internal helm charts are stored in harbor folders with -helm suffix. Adding the whole public project doesn't work natively anymore, so each separate chart should be added as a separate repo.// If you have a real need to add the whole project, please contact support for finding a possible solution.//
5.4	250	{{/info}}
	251
6.3	252	(% class="p1" %)
10.8	253	Choose OCI repository in Target and for url, use ##oci:~/~/registry-<domain>.devops.t-systems.net/<project>-helm/<chartname>##
6.2	254
10.10	255	(% class="box" %)
	256	(((
	257	Replace ##<domain>## , ##<project>## and ##<chartname> ##as necessary to match your set-up. Your charts should be stored in ##<project>-helm ##repository in Harbor, which is created by default when project is created in portal.
	258	)))
6.3	259
	260	(% class="p1" %)
	261	For Authentication, select "Create a HTTP Basic Auth Secret" and provide the Username and Password of the Harbor robot account from the previous section.
	262
5.4	263	(% class="wikigeneratedid" %)
6.2	264	[[image:1765208347952-345.36.18.png\|\|height="449" width="849"]]
5.4	265
7.1	266	(% class="wikigeneratedid" %)
	267	Click Create.
	268
10.10	269	(% class="wrapped" %)
	270	\|=(((
	271	Field
	272	)))\|=(((
	273	Value
	274	)))
	275	\|=(((
	276	Name
	277	)))\|(((
10.11	278	sdcloud-sdportal
10.10	279	)))
	280	\|=(((
	281	Description
	282	)))\|(((
10.11	283	Sdportal charts of sdcloud project
10.10	284	)))
	285	\|=(((
	286	Index URL
	287	)))\|(((
10.12	288	oci:~/~/registry.sdc.t-systems.net/sdcloud-helm/sdportal
10.10	289
	290	{{info}}
10.11	291	Now we should target a chart repo directly, not the whole project. In you need to reference the whole project with a lot of repos, please contact support to find a possible solution.
10.10	292	{{/info}}
	293	)))
	294
21.1	295	== Migrating chart repositories in rancher to new OCI Repository format ==
10.12	296
11.3	297	(% class="box warningmessage" %)
	298	(((
25.1	299	ChartMuseum is deprecated. All harbor charts are removed from ChartMuseum, and old HTTP(S)-based chart repositories no longer work in Rancher (for internal harbor charts).
11.3	300	)))
10.13	301
15.4	302	(% class="box" %)
	303	(((
24.4	304	All your charts are available in the corresponding `<pkey>-helm` OCI project.
15.4	305	)))
	306
12.15	307	There are two ways to migrate your repositories:
12.6	308
14.1	309	1. ##Direct Transition (Editing the Existing Repository)##
14.3	310	1*. Change the target to “OCI Repository”.
25.1	311	1*. Update the URL as required (the repository name cannot be changed) and add a new robot account for helm project, check documentation above
14.3	312	1*. After saving, installed apps will automatically start using the updated repository.
	313	1*. (% class="box" %)
14.2	314	(((
12.15	315	Important limitation: OCI repositories must point directly to a single chart repository, not to a parent folder.
	316	If your old repository included several charts (for example “bitbucket” and “jira”), then after switching to OCI you can only target one chart (e.g. “bitbucket”).
	317	The other charts will no longer receive updates through this repo, and you will still need to create additional repositories for each individual chart.
14.2	318	)))
15.2	319	1. Add New Repositories One by One (Recommended), preserve the old one till the end. This approach allows a smooth transition while the old ChartMuseum repository continues to function. You can:
	320	1*. Create a new OCI repository for each chart,
	321	1*. Keep the old ChartMuseum repo enabled during the migration,
	322	1*. Migrate applications gradually following the steps described here.
15.3	323	1*. This avoids disruptions and allows controlled migration.
22.1	324
15.3	325	1. //Special Case: Old Repo Targeting Multiple Chart Repos//
15.4	326	If your existing repository targets multiple chart repositories and you need the new OCI setup to behave the same way, please contact support.
12.15	327
11.3	328	\| Term \| Meaning
	329	\| Old Repository \| The existing HTTP/HTTPS Harbor ChartMuseum repository.
	330	\| New Repository \| The new OCI-based Helm chart repository created for your project (e.g. `<chart-repo-name>` in `<pkey>-helm`).
11.1	331
11.3	332	##__Why This Migration Is Required:__##
11.1	333
25.1	334	* ##ChartMuseum is deprecated.##
11.3	335	* ##Applications deployed from old repos keep a reference to that repo inside their labels.##
	336	* ##Without updating the application to point to the new OCI repo, Rancher will not detect new chart versions from new repository.##
11.1	337
11.3	338	## Migration Steps:##
11.1	339
11.3	340	1. ##Create the New OCI Repository in Rancher##
	341	11. Go to Apps → Repositories.
	342	11. Add a new repository of type OCI.
19.1	343	11. Name it similarly to your old repo name (e.g. `<chart-repo-name>-oci`). __You can't name it the same and can't rename it later.__
11.3	344	11. Point it to the new OCI endpoint.
12.4	345	1. ##Disable the Old ChartMuseum Repository Temporarily##
	346	##This step ensures that Rancher resolves charts from the new OCI repo.##
11.3	347	11. Go to Apps → Repositories.
	348	11. Disable the old HTTP(S)-based repository.
	349	11. Keep it disabled until the migration is done.
16.2	350	[[image:1765548124989-482.59.06.png\|\|height="152" width="485"]]
11.3	351	1. ##Update Existing Applications to Use the New OCI Repo##
12.3	352	Applications deployed with the old repository still contain the old repo name in their metadata. You must upgrade them once to transition.
11.3	353	11. Go to Apps → Installed Apps.
	354	11. Open the application that was deployed using the old repo.
16.2	355	11. Click Edit/Upgrade.
17.2	356	[[image:1765548598644-830.png\|\|height="138" width="811"]]
18.2	357	11. In the list of available chart repositories (scroll to the bottom), select the new OCI repository. Or enter the chart name in search bar:
	358	[[image:1765548750604-334.png\|\|height="293" width="308"]]
11.3	359	11. Choose the chart version you want to deploy (same or newer).
	360	11. Click Upgrade.
12.3	361	1. ##Re-enable the Old Repository (Optional) ##
	362	If you still need the old repo for other apps, re-enable it after the migration steps above.
	363	Note: Even if a newer chart version exists in the old repository, your migrated app will not see it, because it is no longer connected to that repo
11.2	364
23.1	365	##If you want to move an app back to the old repository:##
	366
11.1	367	1. Temporarily disable the new OCI repo.
12.2	368	1. Enable the old ChartMuseum repo.
	369	1. Open the application → Upgrade.
	370	1. Select the chart from the old repo.
	371	1. Save.
11.1	372
	373	This will reconnect the app to the old repository.
	374
23.1	375	= Automated deployments with Jenkins =
11.1	376
1.1	377	In this section, we describe(% style="color:#172b4d" %) how to set-up automated builds, tests and deployments for Jenkins.
	378
	379	== Prerequisites ==
	380
	381	In order to facilitate the connection between Jenkins and Rancher for the automatic deployments to be possible when a new software version is built, a new technical user to handle this action is required.
	382
	383	In case you don't have one, create a new technical user by following the instructions at [[Creating technical users>>doc:DevOps Portal for Admins.WebHome\|\|anchor="creating_tech_users"]].
	384
	385	== (% style="color:#172b4d" %)Download kubeconfig(%%) ==
	386
	387	(% style="color:#172b4d" %)Connect to Rancher and navigate to your cluster, then in the right top menu, click "Download KubeConfig" as shown in the following image~:
	388	[[image:attach:download_kubeconfig.png\|\|height="150"]]
	389
	390	(% style="color:#172b4d" %)The downloaded kubeconfig file will have the same name as the cluster.
	391
	392	== Deploy kubeconfig to Jenkins ==
	393
	394	In order to be able to automatically deploy your software using Jenkins, follow the next steps:
	395
	396	* Login to your DevOps Portal account and click "Project Credentials" in the "Continuous Integration & Delivery" section.
	397	[[image:image-2024-3-29_12-4-45.png\|\|alt="https://prd.sdc.t-systems.net/confluence/download/attachments/118161601/image-2024-3-29_12-4-45.png?version=1&modificationDate=1711706685672&api=v2" data-xwiki-image-style-border="true" height="198"]]
	398
	399	* Click "Add Credentials"
	400	* Upload the kubeconfig file:
	401
	402	[[image:image-2024-1-3_16-35-29.png\|\|alt="https://prd.sdc.t-systems.net/confluence/download/attachments/118161601/image-2024-1-3_16-35-29.png?version=1&modificationDate=1704292529367&api=v2&effects=drop-shadow" data-xwiki-image-style-border="true" height="400"]]
	403
	404	* Choose "Secret file" from "Kind" dropdown
	405	* Click "Browse" and select your previously downloaded kubeconfig file
	406	* The "ID" field will be used in parameterized pipelines. We propose the prefix "kubeconfig-deployer-" followed by the project name (if the project name contains spaces, please replace them with "-") in order to be consistent and to make a clear differentiation between credential destinations. In the end, this is our proposal and conduct to follow, but of course you are free to name the credentials as you decide it fits best in your organization.
	407	* For the "Description" field we suggest to provide details about the destination and use of these credentials.
	408	* At the end, click "Create"
	409
	410	== Create a build and deploy pipeline ==
	411
	412	An application - more precisely, a helm chart - can now be built, tested and deployed automatically from Jenkins using the [[Jenkins Shared Library>>doc:Jenkins.Jenkins Shared Library.WebHome]] provided by DevOps-as-a-Service. Import the ##sdcloud## library in your Jenkinsfile and call the ##sdcPipeline## script, like shown in the following snippet:
	413
	414	{{code language="groovy"}}
	415	@Library('sdcloud') _
	416
	417	sdcPipeline()
	418	{{/code}}
	419
	420	The example above will run the build & deploy pipeline with its default configuration, which means
	421
	422	* Only the build and test steps will be executed but the built helm chart won't be deployed. To also include the deployment step, set the ##deployHelmChart## parameter to ##true##:
	423	{{code language="groovy"}}sdcPipeline(deployHelmChart: true){{/code}}
	424
	425	* The smoke test step expects a service responding with an HTTP 20x for a request sent to path "/" and port 80 using http. If your service uses different paths, ports, protocols, or arguments, set the corresponding ##sdcPipeline## parameters ##containerProtocol##, ##containerPort##, ##containerContextPath##, and ##containerArgs## accordingly. E.g. to adapt the protocol and the context path, do
	426	{{code language="groovy"}}sdcPipeline(
	427	containerPort: 8080,
	428	containerContextPath: '/solarcalculator'
	429	){{/code}}
	430
	431	There is a lot more to customize. Please refer to [[the customization section of the Jenkins Shared Library documentation>>doc:Jenkins.Jenkins Shared Library.WebHome\|\|anchor="pipeline_customization"]] for the full list of parameters.

Wiki source code of Rancher 2

DevOps-as-a-Service