opentofu
rook
opentofu | rook | |
---|---|---|
46 | 51 | |
21,390 | 12,027 | |
6.8% | 0.8% | |
9.8 | 9.9 | |
about 18 hours ago | 5 days ago | |
Go | Go | |
Mozilla Public License 2.0 | Apache License 2.0 |
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.
opentofu
-
Terraform Init โ Command Overview
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. OpenTofu is an open-source version of Terraform that will expand on Terraform's existing concepts and offerings. It is a viable alternative to HashiCorp's Terraform, being forked from Terraform version 1.5.6.
- Opentofu v1.7.2 Bugfix Release
-
What is OpenTofu?
The OpenTofu initiative was launched with significant initial support, boasting over 18 full-time equivalents (FTEs) committed to the project from four companies. The manifesto has been endorsed by over 140 companies, involving 11 projects with the participation of over 700 individuals. Moreover, the manifesto has received more than 35,000 GitHub stars, and the fork itself has garnered over 6,000 stars in just one week.
-
How to deploy your own website on AWS
Terraform/OpenTofu installed. We use Terraform in this article.
-
Oracle goes vegan: Dumps Terraform for OpenTofu
It's great to see more companies adopting OpenTofu!
As a side note, we've recently released OpenTofu 1.7 with end-to-end state encryption, enhanced provider-defined functions, and a bunch more[0].
If you've been holding out with the migration, now is the perfect moment to take another look, and join the many companies that have already migrated!
[0]: https://github.com/opentofu/opentofu/releases/tag/v1.7.0
Note: Tech Lead of the OpenTofu project
-
OpenTofu v1.7: Enhanced Security with State File Encryption
and more.
-
OpenTofu 1.7.0 is out with State Encryption, Dynamic Provider-defined Functions
Hey!
> With OpenTofu exclusive features making such an early debut, is the intention to remain a superset of upstream Terraform functionality and spec, or allow OpenTofu to diverge and move in its own direction?
The intention is to let it diverge. There will surely be some amount of shared new features, but we're generally going our own way.
> Will you aim to stick to compatibility with Terraform providers/modules?
Yes.
Regarding providers, we might introduce some kind of superset protocol for providers at some point, for tofu-exclusive functionality, but we'll make sure to design it in a way where providers keep working with both Terraform and OpenTofu.
Regarding modules, this one will be more tricky, as there might Terraform languages features that aren't supported in OpenTofu and vice-versa. We have a proposal[0] to tackle this, and enable module authors to easily create modules with support for both, even when using some exclusive features of any one of them.
> Is the potential impact of community fragmentation on your mind as many commercial users who donโt care about open source ideology stick to the tried-and-true Hashicorp Terraform?
We've talked to a lot of people, and we've met many who see the license changes as a risk for them, while OpenTofu, with its open-source nature, is the less-risky choice. That includes large enterprises.
> Is there any intention to try and supplement the tooling around the core product to provide an answer to features like Terraform Cloud dashboard, sentinel policies and other things companies may want out of the product outside of the command line tool itself?
That's mostly covered by the companies sponsoring OpenTofu's development: Spacelift (I work here), env0, Scalr, Harness, Gruntworks.
[0]: https://github.com/opentofu/opentofu/issues/1328
- IBM to Acquire HashiCorp, Inc
-
IBM Planning to Acquire HashiCorp
Please remember to file in a calm and orderly fashion toward the exits and remember: IBM killed Centos for profit.
Terraform users can pick up their new alternative here:
https://opentofu.org/
and for those of you with Vault, you can find your new alternative here:
https://openbao.org/
-
Grant Kubernetes Pods Access to AWS Services Using OpenID Connect
OpenTofu v1.6
rook
-
Ceph: A Journey to 1 TiB/s
I have some experience with Ceph, both for work, and with homelab-y stuff.
First, bear in mind that Ceph is a distributed storage system - so the idea is that you will have multiple nodes.
For learning, you can definitely virtualise it all on a single box - but you'll have a better time with discrete physical machines.
Also, Ceph does prefer physical access to disks (similar to ZFS).
And you do need decent networking connectivity - I think that's the main thing people think of, when they think of high hardware requirements for Ceph. Ideally 10Gbe at the minimum - although more if you want higher performance - there can be a lot of network traffic, particularly with things like backfill. (25Gbps if you can find that gear cheap for homelab - 50Gbps is a technological dead-end. 100Gbps works well).
But honestly, for a homelab, a cheap mini PC or NUC with 10Gbe will work fine, and you should get acceptable performance, and it'll be good for learning.
You can install Ceph directly on bare-metal, or if you want to do the homelab k8s route, you can use Rook (https://rook.io/).
Hope this helps, and good luck! Let me know if you have any other questions.
-
Running stateful workloads on Kubernetes with Rook Ceph
Another option is to leverage a Kubernetes-native distributed storage solution such as Rook Ceph as the storage backend for stateful components running on Kubernetes. This has the benefit of simplifying application configuration while addressing business requirements for data backup and recovery such as the ability to take volume snapshots at a regular interval and perform application-level data recovery in case of a disaster.
-
People who run Nextcloud in Docker: Where do you store your data/files? In a Docker volume, or on a remote server/NAS?
This is beyond your question but might help someone else: I switch from docker-compose to kubernetes for my home lab a while ago. The storage solution I've settled on is Rook. It was a bit of up-front work learning how to get it up but now that it's done my storage is automatically managed by Ceph. I can swap out drives and Ceph basically takes care of everything itself.
-
Rook/Ceph with VM nodes on research cluster?
The stumbling point I am at is I want to use rook.io(Ceph) as my storage solution for the cluster. The Ceph prerequisites are one of the following:
-
Asking for recommendation on remote Kubernetes storage for a small cluster and databases
Have you looked at Rook?
-
Want advice on planned evolution: k3os/Longhorn --> Talos/Ceph, plus Consul and Vault
I've briefly run ceph in an external mode, you can actually use a rook deployment to manage it (sort of). Here is the documentation for doing that. For me it didn't pass my testing phase because I need better networking equipment before I can try that.
-
ATARI is still alive: Atari Partition of Fear
This article explains the data corruption issue happened in Rook in 2021. The root cause lies in an unexpected place and can also occurs in all Ceph environment. It's interesting that Rook had started to encounter this problem recently even though this problem has existed for a long time. It's due to a series of coincidences. I wrote this article because the word "Atari" used in a non-historical context in 2021.
-
How to Deploy and Scale Strapi on a Kubernetes Cluster 2/2
Rook (this is a nice article for Rook NFS)
-
Running on-premise k8s with a small team: possible or potential nightmare?
Storage: Favor any distributed storage you know to start with for Persistent Volumes: Ceph maybe via rook.io, Longhorn if you go rancher etc
-
My completely automated Homelab featuring Kubernetes
I've dealt with a lot of issues that are very close to just unplugging a node. Unfortunately on node lost, my stateful workloads using rook-ceph block storage won't migrate over to another node automatically due to an issue with rook. Stateless apps (ingress nginx, etc..) not using rook-ceph block failover to another node just fine. I've kind of accepted this for now and I know Longhorn has a feature that makes this work but I find rook-ceph to be more stable for my workloads.
What are some alternatives?
adoptium
longhorn - Cloud-Native distributed storage built on and for Kubernetes
datadog-static-analyzer - Datadog Static Analyzer
ceph-csi - CSI driver for Ceph
hnrss - Custom, realtime RSS feeds for Hacker News
velero - Backup and migrate Kubernetes applications and their persistent volumes
awesome-ai-safety - ๐ A curated list of papers & technical articles on AI Quality & Safety
Nginx Proxy Manager - Docker container for managing Nginx proxy hosts with a simple, powerful interface
Cap'n Proto - Cap'n Proto serialization/RPC system - core tools and C++ library
Ceph - Ceph is a distributed object, block, and file storage platform
tabby - Self-hosted AI coding assistant
hub-feedback - Feedback and bug reports for the Docker Hub