Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
K.N Cloud — High-Performance KVM VPS in Miami,Frankfurt and Amsterdam
VDS.net
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
CloudLinux
MeduzaVPN
Servury - Anonymous & Privacy-focused VPS Hosting
Animated Silicon Kiwi cloud ad featuring VPS from $4.90/month, 100 GB S3 storage from $1.49/month, Kiwi Apps from $12/month and cloud backup from $3/month

Categories

In this Discussion

Home › General
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Introducing BMAC - Build My App Cloud

OtterFlipOtterFlip Member
edited 1:43AM in General

So you've got your bare metal. Now what?

We built BMAC as tool to simplify taking blank machines and turning them into a usable harness for your webapps, with many of the advanced features you expect from the big cloud players but with the cost of your own hardware. BMAC is fully open-source and licensed under the GPLv3.

One of the main features we shot for was minimal-downtime during failures. You can't really do that with just a single machine, but with two machines in a cluster it's doable, and that's our basic config. But what happens with that second machine when it's just sitting there waiting to act as a failover host? Well we take full advantage of that second machine while the first one is busy hosting your webapp(s). The second machine has sync state of the production workload, so we leverage that synced-state on the standby host in order to be able to immediately spin-up staging VMs, without any extra copy, based on the FULL STATE of your production VM running on your production machine, but without affecting your production state at all. This means you get to test your new changes, in staging, against the actual full and true state of your production environment, database and all, without any extra wasted time and space making a copy. This is all thanks to the magic wizardy of how ZFS data can be sync'd across the hosts and how you can create Copy-on-Write (CoW) lightweight instant "linked clones" of a ZFS snapshot, which is how we pull this off on the standby host. It's an incredibly useful feature, and ensures that your standby host doesn't just sit there idle waiting for a failure event. Here are some diagrams to explain how this works.

BMAC just reached its v1.0.0 milestone, which means we're using it in production ourselves and we've fully tested all of its scripts for that release (tested from a Ubuntu x64 workstation - many of them do run on macOS though, but ideally you run these from a Debian-based x64 Linux environment). And BMAC is pretty opinionated about some of its requirements because ... well because we made it for ourselves. However it can be pointed at any random machines with NVMe drives and used to set them up, independent of our own requirements, so it's generically-useful even today.

If you want to get a better understand of how you can use BMAC in your scenario, I suggest you drop the project's URL into your favorite chatbot and ask it to help you to understand what it can do for you.

Here's the project. Hope it helps!

https://github.com/OtterFlip/bmac

Disclaimer: You'll notice we're using currently using FiberState to lease our dedicated bare-metal. We're not associated with them in any way other than being a customer, at the moment. But this explains why some aspects of BMAC discuss FiberState. It's definitely not necessary to use FiberState if you're using BMAC.

Thanked by 1nghialele

Comments

  • nghialelenghialele Member

    What You Need to Use BMAC

    2 servers with UEFI BIOS, each with their own public IP and Internet gateway connection on a primary NIC, and a private network connection between these two servers on a secondary NIC on each (can be a VLAN). We prefer FiberState's 'Dedicated Server' option (we have no affiliation, we're just a satisfied customer as FiberState is competitively-priced, particularly if you pay for a year in advance). These will be your main cluster hosts, hosting the guest VMs which in turn host your webapp(s). You can add more than 2 servers if you like, but start with 2.
Each server must have at least two physical NVMe hard disks of the same nominal capacity (their exact byte capacities may differ by up to 1%) for the ESP and OS partitions
1 ultra-cheap VPS host with a public IP address, such as a $5/month Shared CPU Nanode 1GB VPS at Linode. This node's sole purpose will be to play the role of a QDevice, to vote in your cluster quorum to break tie votes.
A developer workstation running a debian-based Linux distro (we made and tested this with x64 Ubuntu) to run BMAC's scripts. This is required for the host setup scripts, but the prod/staging scritps work on macOS too.
A Tailscale account (the free account will work fine)
Your app's domain (ex: 'myapp.com'), managed at Cloudflare (not essential, but our guides assume this)

    Great, I just need 1 VPS and Coolify/Dokploy.

    Or maybe just raw dogging Docker/Proxmox on a Dedi.

    Your software need 3 separated server and tons of other things brother.

  • OtterFlipOtterFlip Member
    edited 1:48AM

    Yeah, this is for folks who want fault-tolerance, high-availability, a minimal-downtime upgrade path, etc, while also managing the bare metal itself. It's an opinionated stack with a lot of features not everyone needs or wants.

  • nghialelenghialele Member

    Yes, but why make things 300% more complicated.

  • OtterFlipOtterFlip Member

    Totally fair question. If your requirements are satisfied by one VPS running Coolify/Dokploy, then you absolutely should do that. It's much simpler.

    For us, there's a scaling cost curve that gets extremely expensive at scale, and by owning all your own hardware (especially if you're using refurb) you can cut down on the cost enormously. We calculated major savings not far out, actually. Each workload is different in the scaling requirements and so this isn't a fit for everyone. Probably not a fit for many. It's more for those who really need to manage the hardware itself.

    Thanked by 2nghialele mans_xd
  • OtterFlipOtterFlip Member
    edited 1:38AM

    And... it may be 300x more complicated, not 300%. lol
    But hey, it's free, and it's out there, so y'know - you can take it or leave it and no harm done.

    Thanked by 2nghialele mans_xd
  • nghialelenghialele Member

    @OtterFlip said:
    And... it may be 300x more complicated, not 300%. lol
    But hey, it's free, and it's out there, so y'know - you can take it or leave it and no harm done.

    No offense mate, what I saw is complicating things. And I said it.

  • OtterFlipOtterFlip Member

    Yup, no argument here. :)

Sign In or Register to comment.