community.kubernetes
api-spec
Our great sponsors
| community.kubernetes | api-spec | |
|---|---|---|
| 3 | 1 | |
| 265 | 1 | |
| - | - | |
| 2.8 | 5.9 | |
| over 2 years ago | 11 months ago | |
| Makefile | Shell | |
| GNU General Public License v3.0 only | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
community.kubernetes
-
Ansible 4.0.0 final has been released
It's hard to say. I don't see too much point in running Ansible inside Terraform or Terraform inside Ansible (yes, you can go either way). Ansible lagged for years on its support of kubernetes and helm (it had it, but it didn't work). Now (like in the last 12 months) got good support for both, but it might be too late. Terraform has the majority of mind share when it comes to Kubernetes support.
If you're only doing AWS or Google Cloud, Ansible can do that. Whether it does it better or worse than Terraform is all dependent on your use case.
If you're doing anything on premise, or outside of GCP/AWS, Ansible can do that as well. From the using OOB management (HP iLO/Dell iDRAC) to install the OS, to configuring vmware clusters to deploying k8s to declaring resources within k8s. Got network switches and firewalls at your office? You can manage that with Ansible. If you have a bunch of edge compute, Ansible can manage that as well.
What it comes down to is if you've got teams working with anything outside of AWS/GCP. They'll probably be using Ansible, and since you've already go Ansible knowledge across your organization, it would make sense to leverage that expertise and Ansible's cloud integrations.
All of that said - Terraform is much more popular when it comes to the major cloud platforms. If all you have is cloud, then you'll probably start with Terraform and stay there.
https://github.com/ansible-collections/community.kubernetes
-
Terraform or Ansible for Kubernetes deployment
https://registry.terraform.io/providers/hashicorp/kubernetes/latest https://github.com/ansible-collections/community.kubernetes
-
Ansible for Kubernetes
I would like to use Ansible only for deployment. This is save to use it https://github.com/ansible-collections/community.kubernetes right?
api-spec
-
How we optimized PostgreSQL queries 100x
GitHub assigns the so-called node identifier to each API object, e.g., a pull request. It’s an opaque string: for example, athenianco/api-spec#66 is PR_kwDOFlTa5c4zPMUj. So we naturally decided to use node IDs as primary keys. Everything worked fine until…
What are some alternatives?
keydb-operator - A KeyDB (Drop-In Alternative to Redis) Operator for Kubernetes, based on Ansible Operator SDK.
freqtrade-do - Setting up freqtrade (Crypto trading bot) on DigitalOcean
k8s-deployment - Reconmap Kubernetes deployment files
community.zabbix - Zabbix Ansible modules
pyinfra - pyinfra automates infrastructure using Python. It’s fast and scales from one server to thousands. Great for ad-hoc command execution, service deployment, configuration management and more.
ansible-collection-nginx - Ansible collection for NGINX
k8s-vagrant-multi-node - A Kubernetes Vagrant Multi node environment using kubeadm.
salt-contrib - Salt Module Contributions
marionette - Something like puppet, for the localhost only.
Pulumi - Pulumi - Infrastructure as Code in any programming language. Build infrastructure intuitively on any cloud using familiar languages 🚀
semver - Semantic Versioning Specification