Closed tu1h closed 3 months ago
In theory this sounds great however that means including manifests with this repo which we use to do, however we switched to downloading them from the web because it was too much to maintain between versions.
If there's a way that doesn't include making those manifests part of the repo and is easy to maintain between versions I am all ears.
Maybe we could provide the ability of airgap but not the offline package directly. It could be completed by extracting some options and scripts. So image and file lists could be parsed and output by running scripts, then users can build and package using the lists and loaded to the image registry(e.g. docker registry/harbor) and HTTP server(e.g. minio/nginx) when ready to install. Before users install the cluster, they should set options to override the original address/url.
For files example: https://github.com/techno-tim/k3s-ansible/blob/072f1a321d54a91dba1ec00b6c99fb20ffec3d28/roles/k3s_server/tasks/kube-vip.yml#L13
We could change it like this:
url: "{{ kube_vip_cloud_controller_yaml_download_url }}"
In default/main.yaml
raw_githubusercontent_url: https://raw.githubusercontent.com
kube_vip_cloud_controller_yaml_download_url: "{{ raw_githubusercontent_url }}/kube-vip/kube-vip-cloud-provider/{{ kube_vip_cloud_provider_tag_version | default('main') }}/manifest/kube-vip-cloud-controller.yaml"
For images, e.g. : https://github.com/techno-tim/k3s-ansible/blob/072f1a321d54a91dba1ec00b6c99fb20ffec3d28/roles/k3s_server/templates/vip.yaml.j2#L57
We could change it like this:
image: "{{ kube_vip_image_repo }}:{{ kube_vip_image_tag }}"
In default/main.yaml
kube_vip_tag_version: xxx
github_image_repo: "ghcr.io"
kube_vip_image_repo: "{{ github_image_repo }}/kube-vip/kube-vip"
kube_vip_image_tag: "{{ kube_vip_tag_version }}"
All of them just like Kubespray:
At this time I don't think we are going to support an air gapped solutions. This introduces a lot of complexity for all of the image repos we use in this playbook. It will almost double the amount of variables we have (repo + tag x component). For this reason I am closing this request but thank you!
This repo is functional and extensible, but many scenarios are not on the Internet, is there a plan to support airgap? Or whether our contributions to this repo would be accepted?