0b8d249c23
The health checks in `VmHost#check_pulse` and `HostNexus#available?` were simple SSH access attempts, but this was not sufficient for detecting issues in the disks. This change adds a simple disk IO to the health check commands. The disk I/O added for the health check is a simple read from /dev/zero into a random file in /tmp. This would be enough to detect any obvious failures related to the disks. Note that, in cases of multiple disks are mounted into the file system (`/`) via raid, this approach may not detect a single disk failure as long as the system works. Note: Through the codebase, health checks for the monitor (`check_pulse`) and progs (`available?`) are duplicated, which is also the case for VM host. We can argue about unifying the health check and availability detection in general as a next step. Still, I wanted to make some deduplication by extracting the shell command to be used for health check into a `VmHost` constant. Future work: While some disk i/o would be enough to check for obvious problems, as a future work we can consider monitoring SMART bits, preferably with less frequency and less severity. |
||
|---|---|---|
| .github | ||
| assets | ||
| bin | ||
| cache | ||
| config | ||
| demo | ||
| lib | ||
| migrate | ||
| model | ||
| prog | ||
| public | ||
| rhizome | ||
| routes | ||
| scheduling | ||
| serializers | ||
| spec | ||
| views | ||
| .by-session-setup.rb | ||
| .dockerignore | ||
| .editorconfig | ||
| .envrc | ||
| .gitignore | ||
| .rspec | ||
| .rubocop.yml | ||
| .spectral.yaml | ||
| .tool-versions | ||
| clover.rb | ||
| clover_api.rb | ||
| clover_runtime.rb | ||
| clover_web.rb | ||
| config.rb | ||
| config.ru | ||
| db.rb | ||
| DEVELOPERS.md | ||
| Dockerfile | ||
| Gemfile | ||
| Gemfile.lock | ||
| LICENSE | ||
| loader.rb | ||
| model.rb | ||
| openapi.yml | ||
| package-lock.json | ||
| package.json | ||
| Procfile | ||
| Rakefile | ||
| README.md | ||
| redocly.yaml | ||
| tailwind.config.js | ||
| ubid.rb | ||
Ubicloud 
Ubicloud is an open source cloud that can run anywhere. Think of it as an open alternative to cloud providers, like what Linux is to proprietary operating systems.
Ubicloud provides IaaS cloud features on bare metal providers, such as Hetzner, Leaseweb, and AWS Bare Metal. You can set it up yourself on these providers or you can use our managed service. We're currently in public beta.
Quick start
Managed platform
You can use Ubicloud without installing anything. When you do this, we pass along the underlying provider's benefits to you, such as price or location.
Build your own cloud
You can also build your own cloud. To do this, start up Ubicloud's control plane and connect to its cloud console.
git clone git@github.com:ubicloud/ubicloud.git
# Generate secrets for demo
./demo/generate_env
# Run containers: db-migrator, app (web & respirate), postgresql
docker-compose -f demo/docker-compose.yml up
# Visit localhost:3000
The control plane is responsible for cloudifying bare metal Linux machines. The easiest way to build your own cloud is to lease instances from one of those providers. For example: https://www.hetzner.com/sb
Once you lease instance(s), run the following script for each instance to cloudify the instance. By default, the script cloudifies bare metal instances leased from Hetzner. After you cloudify your instances, you can provision and manage cloud resources on these machines.
# Enter hostname/IP and provider, and install SSH key as instructed by script
docker exec -it ubicloud-app ./demo/cloudify_server
Later when you create VMs, Ubicloud will assign them IPv6 addresses. If your ISP doesn't support IPv6, please use a VPN or tunnel broker such as Mullvad or Hurricane Electric's https://tunnelbroker.net/ to connect. Alternatively, you could lease IPv4 addresses from your provider and add them to your control plane.
Why use it
Public cloud providers like AWS, Azure, and Google Cloud have made life easier for start-ups and enterprises. But they are closed source, have you rent computers at a huge premium, and lock you in. Ubicloud offers an open source alternative, reduces your costs, and returns control of your infrastructure back to you. All without sacrificing the cloud's convenience.
Today, AWS offers about two hundred cloud services. Ultimately, we will implement 10% of the cloud services that make up 80% of that consumption.
Example workloads and reasons to use Ubicloud today include:
-
You have an ephemeral workload like a CI/CD pipeline (we're integrating with GitHub Actions), or you'd like to run compute/memory heavy tests. Our managed cloud is ~3x cheaper than AWS, so you save on costs.
-
You want a portable and simple app deployment service like Kamal. We're moving Ubicloud's control plane from Heroku to Kamal; and we want to provide open and portable services for Kamal's dependencies in the process.
-
You have bare metal machines sitting somewhere. You'd like to build your own cloud for portability, security, or compliance reasons.
Status
Ubicloud is in public beta. You can provide us your feedback, get help, or ask us to support your network environment in the Community Forum.
We follow an established architectural pattern in building public cloud services. A control plane manages a data plane, where the data plane leverages open source software. You can find our current cloud components / services below.
-
Elastic Compute: Our control plane communicates with Linux bare metal servers using SSH. We use Cloud Hypervisor as our virtual machine monitor (VMM); and each instance of the VMM is contained within Linux namespaces for further isolation / security.
-
Networking: We use IPsec tunneling to establish an encrypted and private network environment. We support IPv4 and IPv6 in a dual-stack setup and provide both public and private networking. For security, each customer’s VMs operate in their own networking namespace. For firewalls and load balancers, we use Linux nftables.
-
Block Storage, non replicated: We use Storage Performance Development Toolkit (SPDK) to provide virtualized block storage to VMs. SPDK enables us to add enterprise features such as snapshot and replication in the future. We follow security best practices and encrypt the data encryption key itself.
-
Attribute-Based Access Control (ABAC): With ABAC, you can define attributes, roles, and permissions for users and give them fine-grained access to resources. You can read more about our ABAC design here.
-
What's Next?: We're planning to work on a managed K8s or metrics/monitoring service next. If you have a workload that would benefit from a specific cloud service, please get in touch with us through our Community Forum.
-
Control plane: Manages data plane services and resources. This is a Ruby program that stores its data in Postgres. We use the Roda framework to serve HTTP requests and Sequel to access the database. We manage web authentication with Rodauth. We communicate with data plane servers using SSH, via the library net-ssh. For our tests, we use RSpec.
-
Cloud console: Server-side web app served by the Roda framework. For the visual design, we use Tailwind CSS with components from Tailwind UI. We also use jQuery for interactivity.
If you’d like to start hacking with Ubicloud, any method of obtaining Ruby and Postgres
versions is acceptable. If you have no opinion on this, our development team uses asdf-vm
as documented here in detail.
Greptile provides an AI/LLM that indexes Ubicloud's source code can answer questions about it.
FAQ
Do you have any experience with building this sort of thing?
Our founding team comes from Azure; and worked at Amazon and Heroku before that. We also have start-up experience. We were co-founders and founding team members at Citus Data, which got acquired by Microsoft.
How is this different than OpenStack?
We see three differences. First, Ubicloud is available as a managed service (vs boxed software). This way, you can get started in minutes rather than weeks. Since Ubicloud is designed for multi-tenancy, it comes with built-in features such as encryption at rest and in transit, virtual networking, secrets rotation, etc.
Second, we're initially targeting developers. This -we hope- will give us fast feedback cycles and enable us to have 6 key services in GA form in the next two years. OpenStack is still primarily used for 3 cloud services.
Last, we're designing for simplicity. With OpenStack, you pick between 10 hypervisors, 10 S3 implementations, and 5 block storage implementations. The software needs to work in a way where all of these implementations are compatible with each other. That leads to consultant-ware. We'll take a more opinionated approach with Ubicloud.