kmf
commented
2 months ago @djdanielsson sounds awesome, similar to ascender-install
Closed djdanielsson closed 1 month ago
kmf
commented
2 months ago @djdanielsson sounds awesome, similar to ascender-install
kurokobo
commented
2 months ago @djdanielsson @kmf Thank you for your ideas.
Yes, this has been considered in the past and is of course technically possible. I also know it is very helpful for users. In fact, I have automated all deployments, including K3s, AWX, EDA Server, and Galaxy NG with Ansible for testing my guide itself in my home lab for each updates.
The concern with automating deployment with Ansible is that the build procedure becomes a black box. I want my guide to not only provide instructions to make it as easy as possible for users to get a working AWX, but also provide a role as a hands-on guide to getting started with Kubernetes, like Kubernetes 101 labs. Since knowledges and skills to use Kubernetes is a necessary part of using recent AWX.
For this reason, I am not actively accustomed to publishing the guide as a playbook, as I want to work through it, step by step, so that users know what they are doing. It may be feasible to at least provide a playbook version as sub-content, rather than replacing the guide entirely. However, I am not sure if this should be done by me personally, as I am just a community member, not Red Hat.
Any thought?
jpmens
commented
2 months ago I for one fully agree with the idea of having a guide one can follow step-by-step to learn how to install k3s, etc., and I've been grateful for the effort presented.
I am not actively accustomed to publishing the guide as a playbook, as I want to work through it, step by step,
Maybe tasks in a playbook could be numbered to correspond with similarly numbered steps in the documentation. That way people reading could see how to implement in a play, and conversely, people following the playbook could refer to the numbered guide sections/steps.
djdanielsson
commented
2 months ago I can see and understand about this being a guide to help learn and agree that if you just provide a black box that isn't as helpful. I think @jpmens idea of linking the current documentation to the code could help explain everything but provide an automated solution at the same time. As for you being "just a community member" these are all open source applications, this is exactly the type of thing community members do, do not feel like you need to have some sort of position or title to be able to contribute, help others, or create solutions. The only difference between you and someone who works on the AWX team is they are getting payed to do it. I am not sure if you keep up with the AWX office hours or not but they even brought up how they were going to add some testing to try and catch some potential issues that they currently do not check for that can happen when using local storage due to how many people use your guide.
kurokobo
commented
2 months ago @jpmens @djdanielsson Thanks for the input and ideas. Tying the guide to the code is indeed a good idea. I will consider if there is a room to implement something. (Of course, I understand that this does not necessarily have to be done by me, and community members other than myself can do this in a separate repository 😃 Contributions and PRs are always welcome!)
djdanielsson
commented
2 months ago you said you already had some code that did this, if you publish what you have already, I could try and help improve/expand it. I can try and build something from scratch but it will take longer.
kurokobo
commented
2 months ago Hmm, the playbooks that I already have is for testing manual procedures in my guides. So the playbooks contains following tasks:
At this time I don't intend to make these playbooks public, because its purpose is different (testing guides v.s. deploying AWX) and it is inappropriate for deploying AWX, and several community members have already published a sort of "wrapper" for my repository.
Some community members have published some playbooks or roles differently than my guide. I don't know if these are all of that.
jpmens
commented
2 months ago Going back to @djdanielsson's original thought, if the guide had parseable bits which could produce the playbook ... something more than a template maybe..
kurokobo
commented
2 months ago I had embedded hidden comments that indicate code blocks in my guides, e.g.: https://github.com/kurokobo/awx-on-k3s/blame/main/README.md#L177
In fact, my (private) playbooks uses these hidden comments to extract commands from markdown files, to imitate manual procedure.
However, it is not appropriate to use this embedded comment for deployment purposes, since the mkdir command, for example, should use the ansible.builtin.file module.
davidmacdonald80
commented
1 month ago I'm still fairly new to kubernetes, I was going to post a new thread but honestly, I think this probably belongs here, i know it isn't a playbook, but since i don't remember seeing a flavor specified in this thread I didn't want to make a playbook out of it. I'm using almalinux, and installing this to get AWX up and running requires a few extra steps. I will leave updating the readme up to a current contributor, you are more than welcome to take credit for my suggestions if that stuff matters to you. I don't know if this applies to other flavors, but from a fresh almalinux install, it does. Some of the steps i am going to post are already in the current readme. I used chatgpt 40 to help me research the steps but I can confirm they work.
sudo tee /etc/yum.repos.d/kubernetes.repo <<EOF [kubernetes] name=Kubernetes baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/ enabled=1 gpgcheck=1 gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni EOF
sudo dnf install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
sudo systemctl enable --now kubelet
https://docs.k3s.io/installation/requirements?os=rhel#operating-systems
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.29.4+k3s1 sh -s - --write-kubeconfig-mode 644
mkdir -p ~/.kube sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config sudo chown $(id -u):$(id -g) ~/.kube/config
cd ~ git clone https://github.com/kurokobo/awx-on-k3s.git cd awx-on-k3s git checkout 2.17.0
kubectl apply -k operator
kurokobo
commented
1 month ago @davidmacdonald80 Hi, you are probably being misled by ChatGPT. I don't see the need to install kubelet, kubeadm and kubectl before installing K3s, since they are bundled with K3s. Also creating ~/.kube/config is also not necessary as long as you use kubectl bundled with K3s.
kurokobo
commented
1 month ago I've been thinking about this for a while, but I've come to the conclusion that it's difficult for me to maintain a strong passion for implementing and continuously maintaining this. While there's always a possibility that I might work on it if I feel like it, at least for now, with the fact that I have returned to my day job after my paternity leave and clearly have less free time than before, there are many other things around AWX and beyond that interest me more and I'd like to spend my time on those.
Thank you to everyone who gave their opinions. I'm sorry I couldn't meet your expectations. If you're interested in this issue, please feel free to implement it in your own repository and share it. Thank you.
Looking over this repo, first off this looks like great content and very useful for someone like myself who does not know a lot about k3s/k8s to deploy AWX on. I was wondering though you say make changes to these config files in your instructions, which made me wonder, what about creating a jinja template instead and use ansible to create these configuration files and deploy them to k3s or at least to a repo that then something like argo could use?