TL;DR
This guide discusses everything needed to build a simple, scalable, and fully binary compatible Raspberry Pi cluster using QEMU, Docker, Docker Compose, and Ansible.
Introduction
The Raspberry Pi is no longer just a low-cost platform for students to learn computing, it’s now a legitimate research and development platform that’s being used for IoT, networking, distributed systems, and software development. It’s even being used administratively in production environments.
Not long after the first Raspberry Pi was released in 2012, several set out to build them into low-cost clusters, often for their research and testing purposes. Interns at DataStax built a multi-datacenter, 32 nodes Cassenda fault-tolerance demo, complete with a big red button to simulate the failure of an entire datacenter. David Guill built a 40-node Raspberry Pi Cluster that was intended to be part of his MSCE thesis. Balena, built “The Beast“, a 120 node Raspberry Pi cluster, for scaled testing of their online platform. And on the extreme end of the spectrum, Oracle built a 1060 node Raspberry Pi Cluster, which they introduced at Oracle OpenWorld 2019.
Innovation with the Raspberry Pi continues as they are turned into everything from wi-fi extenders, security cameras, and even bigger clusters. While the main value of these clusters is inherent in their size and low cost, their popularity makes them an increasingly common development platform. Since the Raspberry Pi uses an ARM processor, this can make development problematic for those of us who work exclusively in the cloud. While commercial solutions exist, we will be building our own emulated cluster using a fully open source stack hosted on Google Compute Engine.
Use Cases
Other than learning from the experience, Dockerizing an emulated Raspberry Pi enables us to do three things. One, it turns into software that would otherwise be a hardware-only device that nobody has to remember to carry around (I’m always losing the peripheral cables). Two, it enables Docker to do for the Pi what Docker does best for everything else: it makes software portable, easy to manage, and easy to replicate. And three, it takes up no physical space. If we can build one Raspberry Pi with Docker, we can build many. If we can build many, we can network them all together. While we may encounter some limitations, this build will emulate a cluster of Raspberry Pi 1s that’s logically equivalent to a simple, multi-node physical cluster.
Emulated Hardware Architecture
While technically not identical, the emulation software we will be using, QEMU, provides an ARM-Versatile architecture that’s roughly compatible with what is found on a Raspberry Pi 1. Some modifications to the kernel are necessary in order for it to work properly with Raspbian, but for our purposes, it’s one of the more stable open source solutions available.
pi@raspberrypi:~$ cat /proc/cpuinfo processor : 0model name : ARMv6-compatible processor rev 7 (v6l)BogoMIPS : 577.53Features : half thumb fastmult vfp edsp java tlsCPU implementer : 0x41CPU architecture: 7CPU variant : 0x0CPU part : 0xb76CPU revision : 7Hardware : ARM-Versatile (Device Tree Support)Revision : 0000Serial : 0000000000000000Compared to a Physical Raspberry Pi 1, they are nearly identical:
pi@raspberrypi:~ $ cat /proc/cpuinfoprocessor : 0model name : ARMv6-compatible processor rev 7 (v6l)BogoMIPS : 697.95Features : half thumb fastmult vfp edsp java tls CPU implementer : 0x41CPU architecture: 7CPU variant : 0x0CPU part : 0xb76CPU revision : 7Hardware : BCM2835Revision : 000dSerial : 000000003d9a54c5Background
What is QEMU?
QEMU is a processor emulator. It supports a number of different processors, but the only thing that we’re interested in is something that can run Raspberry Pi images natively without lot of difficulties. In this case, we’re going to be using QEMU 4.2.0, which supports an ARM11 instruction set that’s compatible with the Broadcom BCM2835 (ARM1176JZFS) chip found on the Raspberry Pi 1 and Zero. We will use ARM1176 support on QEMU, which will allow us to more or less emulate a Raspberry Pi 1. I say more or less because we will still need to use a customized Raspbian kernel in order to boot on the emulated hardware. QEMU support for the Pi is still in development, so our approach to getting it to work here is just a clever hack that will by no means be optimal or efficient in terms of CPU utilization.
QEMU Features
QEMU supports many of the same features found in Docker, however, it can run full software emulation without a host kernel driver. This means that it can run inside Docker, or any other virtual machine, without host virtualization support. The QEMU feature list is extensive, and the learning curve is steep. However, the primary feature that we will be focused on for this build is host port forwarding so that data can be passed to the host.
Dockerized QEMU
One of Docker’s strengths is that it doesn’t handle full-fledged virtualization, but instead relies on the architecture of the host system. Since our host system will be running an Intel processor, we can’t expect Docker to handle ARM operations on its own. So, we will be placing QEMU inside a Docker container. Since Docker is designed to run software at near-native performance, the operational efficiency challenge will be with QEMU itself. QEMU, on the other hand, supports emulations of a machine’s architecture completely with software. The advantage this has is that it can run inside any virtualized system or container, independent of its system architecture. If patient, we could even run a Dockerized Raspberry Pi container inside another Dockerized Raspberry Pi container. The drawback to QEMU is that it has comparatively poor performance compared to other types of virtualization. But we can benefit from the best of both worlds by leveraging QEMU’s ARM emulation while depending on Docker for everything else.
Raspbian
Based on Debian, Raspbian is a popular and well supported operating system for the Raspberry Pi, and is one of the most often recommended for the platform. The community is very active and well managed.
Physical Raspberry Pi Speed Comparison
The following tests are intended as a baseline for comparing our virtualized systems. Since we will be emulating a single-core, these tests are only single-core, single thread, regardless of how many physical cores are incorporated into the architecture.
Raspberry Pi 1 2011,12
Test execution summary: total time: 330.5514s total number of events: 10000 total time taken by event execution: 330.5002 per-request statistics: min: 32.92ms avg: 33.05ms max: 40.94ms approx. 95 percentile: 33.24msThreads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 330.5002/0.00Raspberry Pi 1 A+ V1.1 2014
Test execution summary: total time: 328.7505s total number of events: 10000 total time taken by event execution: 328.6931 per-request statistics: min: 32.71ms avg: 32.87ms max: 78.93ms approx. 95 percentile: 33.03msThreads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 328.6931/0.00Raspberry Pi Zero W v1.1 2017
Test execution summary: total time: 228.2025s total number of events: 10000 total time taken by event execution: 228.1688 per-request statistics: min: 22.76ms avg: 22.82ms max: 35.29ms approx. 95 percentile: 22.94msThreads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 228.1688/0.00Raspberry Pi 2 Model B v1.1 2014
Test execution summary: total time: 224.9052s total number of events: 10000 total time taken by event execution: 224.8738 per-request statistics: min: 22.20ms avg: 22.49ms max: 32.85ms approx. 95 percentile: 22.81msThreads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 224.8738/0.00Raspberry Pi 3 Model B v1.2 2015
Test execution summary: total time: 139.6140s total number of events: 10000 total time taken by event execution: 139.6087 per-request statistics: min: 13.94ms avg: 13.96ms max: 34.06ms approx. 95 percentile: 13.96msThreads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 139.6087/0.00Raspberry Pi 4 B 2018
Test execution summary: total time: 92.6405s total number of events: 10000 total time taken by event execution: 92.6338 per-request statistics: min: 9.22ms avg: 9.26ms max: 23.50ms approx. 95 percentile: 9.27msThreads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 92.6338/0.00Project Requirements
Single Host Specifications
Historically, QEMU has been single-threaded, emulating all cores of a system’s architecture on a single CPU. While that’s no longer the case, we are still going to be emulating a single core Raspberry Pi. We will do some benchmarks later to compare how different CPU limits on each node impacts performance. But for now, we will use one CPU per single-core node. Since QEMU has the potential to use a lot of CPU resources due to its inherent inefficiency, our initial three-node cluster will start with a baseline of at least one CPU per node, leaving one CPU dedicated to the host to avoid performance problems. The VM specs selected for this task are as follows.
Cloud Provider: Google Cloud PlatformInstance Type: n1-standard-4CPUs: 4Memory: 15GBDisk: 100GBOperating System: Ubuntu 18.04 LTSDocker
Installed on the host, we’re also using the default version of Docker that is available on the default apt repository for Ubuntu 18.04 LTS.
# docker -vDocker version 18.09.7, build 2d0083dDocker Compose
# docker-compose -vdocker-compose version 1.25.0, build 0a186604Docker Hub Ubuntu Image
18.04, bionic-20200112, bionic, latestQEMU
Installed inside the Docker container, we will be using the following version of QEMU for ARM:
# qemu-system-arm --versionQEMU emulator version 4.2.0Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developersQEMU Customized Kernel for Raspbian
Loaded from QEMU inside Docker, we will use Dhruv Vyas‘s compiled kernel for Raspbian, which has been modified to be usable with QEMU.
Raspbian Lite Image
Also booted from QEMU, we will use an unmodified version of Raspbian Lite from 9/30/2019.
Expect (Tcl/Tk)
Installed on the Docker container is the following version of Expect:
# expect -vexpect version 5.45.4ssh/sshd
sshd will need to be enable on each Raspbian node, and ssh should be enabled on the host.
Ansible
The following version of Ansible is also being used, along with its other dependencies:
# ansible --versionansible 2.5.1 config file = /etc/ansible/ansible.cfg configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python2.7/dist-packages/ansible executable location = /usr/bin/ansible python version = 2.7.17 (default, Nov 7 2019, 10:07:09) [GCC 7.4.0]Building the Docker Images
QEMU Build Container
We will compile QEMU 4.2.0 from source. It will need all the supporting build tools, so to keep our app container as small as possible, we will create a separate build container for the QEMU build using a minimal version of Ubuntu 18.04 from Docker Hub.
QEMU App Container
Once the QEMU is compiled from source, we will transfer it to the app container. Also from Docker Hub, we will use the same minimal version of Ubuntu 18.04 to host the QEMU binary.
Docker Configuration
The Dockerfile
We will be using the following Dockerfile, which may also be found updated in this guide’s accompanying pidoc repository on Github. Each code snippet below makes up a segment of the Dockerfile. Thanks goes to Luke Child‘s for his work on dockerpi.
Build stage for qemu-system-arm:
FROM ubuntu AS qemu-system-arm-builderARG QEMU_VERSION=4.2.0ENV QEMU_TARBALL="qemu-${QEMU_VERSION}.tar.xz"WORKDIR /qemuRUN apt-get update && \ apt-get -y install \ wget \ gpg \ pkg-config \ python \ build-essential \ libglib2.0-dev \ libpixman-1-dev \ libfdt-dev \ zlib1g-dev \ flex \ bisonDownload source.
RUN wget "https://download.qemu.org/${QEMU_TARBALL}"RUN # Verify signatures...RUN wget "https://download.qemu.org/${QEMU_TARBALL}.sig"RUN gpg --keyserver keyserver.ubuntu.com --recv-keys CEACC9E15534EBABB82D3FA03353C9CEF108B584RUN gpg --verify "${QEMU_TARBALL}.sig" "${QEMU_TARBALL}"Extract tarball.
RUN tar xvf "${QEMU_TARBALL}"Build source.
RUN "qemu-${QEMU_VERSION}/configure" --static --target-list=arm-softmmuRUN make -j$(nproc)RUN strip "arm-softmmu/qemu-system-arm"Build the intermediary pidoc VM app image.
FROM ubuntu as pidoc-vmARG RPI_KERNEL_URL="https://github.com/dhruvvyas90/qemu-rpi-kernel/archive/afe411f2c9b04730bcc6b2168cdc9adca224227c.zip"ARG RPI_KERNEL_CHECKSUM="295a22f1cd49ab51b9e7192103ee7c917624b063cc5ca2e11434164638aad5f4"Transfer binary from build container to app container.
COPY --from=qemu-system-arm-builder /qemu/arm-softmmu/qemu-system-arm /usr/local/bin/qemu-system-armDownload modified kernel and install.
ADD $RPI_KERNEL_URL /tmp/qemu-rpi-kernel.zipRUN apt-get update && \ apt-get -y install \ unzip \ expectRUN cd /tmp && \ echo "$RPI_KERNEL_CHECKSUM qemu-rpi-kernel.zip" | sha256sum -c && \ unzip qemu-rpi-kernel.zip && \ mkdir -p /root/qemu-rpi-kernel && \ cp qemu-rpi-kernel-*/kernel-qemu-4.19.50-buster /root/qemu-rpi-kernel/ && \ cp qemu-rpi-kernel-*/versatile-pb.dtb /root/qemu-rpi-kernel/ && \ rm -rf /tmp/*VOLUME /sdcardThen we copy the entry point script from the host’s main directory.
ADD ./entrypoint.sh /entrypoint.shENTRYPOINT ["./entrypoint.sh"]Build the final app pidoc image with the Raspbian Lite filesystem loaded.
FROM pidoc-vm as pidocARG FILESYSTEM_IMAGE_URL="http://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2019-09-30/2019-09-26-raspbian-buster-lite.zip"ARG FILESYSTEM_IMAGE_CHECKSUM="a50237c2f718bd8d806b96df5b9d2174ce8b789eda1f03434ed2213bbca6c6ff"ADD $FILESYSTEM_IMAGE_URL /filesystem.zipADD pi_ssh_enable.exp /pi_ssh_enable.expRUN echo "$FILESYSTEM_IMAGE_CHECKSUM /filesystem.zip" | sha256sum -cThe entrypoint.sh File
First, the script determines if the filesystem has been downloaded or not, and if not, it downloads and decompresses it.
#!/bin/shraspi_fs_init() { image_path="/sdcard/filesystem.img" zip_path="/filesystem.zip" if [ ! -e $image_path ]; then echo "No filesystem detected at ${image_path}!" if [ -e $zip_path ]; then echo "Extracting fresh filesystem..." unzip $zip_path mv *.img $image_path rm $zip_path else exit 1 fi fi}The script then checks for an empty raspi-init file, which serves as a marker to determine if Expect has been launched previously to enable ssh on Raspbian.
if [ ! -e /raspi-init ]; then touch /raspi-init raspi_fs_init echo "Initiating Expect..." /usr/bin/expect /pi_ssh_enable.exp `hostname -I` echo "Expect Ended..."If Expect has already been previously enabled, then we only need to launch QEMU, without Expect. Note that we are forwarding port 22 on Raspbian to port 2222 inside the Docker container.
else /usr/local/bin/qemu-system-arm \ --machine versatilepb \ --cpu arm1176 \ --m 256M \ --hda /sdcard/filesystem.img \ --net nic \ --net user,hostfwd=tcp:`hostname -I`:2222-:22 \ --dtb /root/qemu-rpi-kernel/versatile-pb.dtb \ --kernel /root/qemu-rpi-kernel/kernel-qemu-4.19.50-buster \ --append "root=/dev/sda2 panic=1" \ --no-reboot \ --display none \ --serial mon:stdiofiEnable SSHD on Raspbian (Expect Tcl/Tk Method)
QEMU doesn’t have a straightforward method for running configuration scripts on boot. And because Raspbian doesn’t come with SSH enabled by default, we will have to turn it on ourselves. Our options are to do it manually or to use some sort of scripting tool that can interact with stdio. Another option is to customize the Raspbian image before installation. This would have to be done on the host, however, as Docker restricts the mounting of new filesystems. In any case, to make this build the most portable and host independent, the most straightforward for our purposes will be to use an Expect script, and have it copied into our Docker image on build.
The pi_ssh_enable.exp File
Since an unmodified Raspbian image has no accessible ports by default, we will use Expect to interface with stdio in QEMU, log in with a default username and password, and enable the sshd listener.
#!/usr/bin/expect -fset ipaddr [lindex $argv 0]set timeout -1spawn /usr/local/bin/qemu-system-arm \ --machine versatilepb \ --cpu arm1176 \ --m 256M \ --hda /sdcard/filesystem.img \ --net nic \ --net user,hostfwd=tcp:$ipaddr:2222-:22 \ --dtb /root/qemu-rpi-kernel/versatile-pb.dtb \ --kernel /root/qemu-rpi-kernel/kernel-qemu-4.19.50-buster \ --append "root=/dev/sda2 panic=1" \ --no-reboot \ --display none \ --serial mon:stdioexpect "raspberrypi login:"send -- "pi\r"expect "Password:"send -- "raspberry\r"expect "pi@raspberrypi:"send -- "sudo systemctl enable ssh\r"expect "pi@raspberrypi:"send -- "sudo systemctl start ssh\r"expect "pi@raspberrypi:"expect eofBuild Image
In the folder with the Dockerfile, we will be building our two containers. The first will be our build container that includes all the dependencies for compiling QEMU, and the other will be our app container for running QEMU.
docker build -t pidoc .Network Forwarding and Troubleshooting
Once the build is complete, bring it up detached and follow the logs.
docker run -itd --name testnode pidocdocker logs testnode -fRaspbian will download and decompressed automatically, and QEMU should begin booting from the image.
Once Raspbian is fully booted, Expect should automatically enable sshd. Log into the docker container and test that SSH is reachable from inside the container on port 2222.
# docker exec -it testnode bashroot@d4abc2f655e6:/# hostname -I172.17.0.3root@d4abc2f655e6:/# cat < /dev/tcp/172.17.0.3/2222SSH-2.0-OpenSSH_7.9p1 Raspbian-10Cancel out and kill the container and remove the volume.
root@d4abc2f655e6:/# exitexit# docker kill testnodetestnode# docker container rm testnodetestnodeTesting the Docker Container
Start/Test Container
We will need to start the container for testing. This is primarily to gain some intuition about the performance of QEMU so that we can better make design decisions regarding our cluster. The system should come up clean with maybe a few benign warnings related to differences between the somewhat more generalized emulated hardware and the expected physical raspberry Pi hardware. I found it necessary to make sure port forwarding was working properly between QEMU and the Docker image so that I could further verify that port forwarding between the Docker image and host was working properly. Our first goal is to double forward SSH so that QEMU is accessible directly from the host.
docker run -itd -p 127.0.0.1:2222:2222 --name testnode pidocdocker logs testnode -fOnce the system again comes online, test for sshd on port 2222 of the host by using ssh to log into Raspbian:
# ssh pi@localhost -p 2222The authenticity of host '[localhost]:2222 ([127.0.0.1]:2222)' can't be established.ECDSA key fingerprint is SHA256:N0oRF23lpDOFjlgYAbml+4v2xnYdyrTmBgaNUjpxnFM.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '[localhost]:2222' (ECDSA) to the list of known hosts.pi@localhost's password:Linux raspberrypi 4.19.50+ #1 Tue Nov 26 01:49:16 CET 2019 armv6lThe programs included with the Debian GNU/Linux system are free software;the exact distribution terms for each program are described in theindividual files in /usr/share/doc/*/copyright.Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extentpermitted by applicable law.Last login: Tue Jan 21 12:24:59 2020SSH is enabled and the default password for the 'pi' user has not been changed.This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.pi@raspberrypi:~ $Testing Fractional CPU Utilization
To run this cluster, we’re using a GCP n1-standard-4 instance (a 4×15) running Ubuntu 18.04 LTS. But we now notice how inefficient QEMU is once Raspbian begins doing anything. Multiple Raspberry Pi instances might stack fine if their idle, but if we want to keep the system viable, we will need to restrict CPU utilization on each instance, or else the system could be rendered unusable once more than a few nodes are put under load. Fortunately, Docker can handle this for us. We have 15GB of ram on this instance, so let’s see what happens if we are slightly more ambitious and squeezed 6 Raspberry Pi containers onto our VM. We will have a whole core left for the host to manage other tasks without much risk of a failure. We can scale this at some point later with Docker Compose.
We will run two test containers at 50% and 100% for benchmark testing.
docker run -itd --cpus="0.50" -p 127.0.0.1:2250:2222 --name pidoc_50_test pidocdocker run -itd --cpus="1.00" -p 127.0.0.1:2200:2222 --name pidoc_00_test pidocAt this point, we technically already have a cluster. We just don’t have a method to manage them, except by hand.
Performance
While a full core allocation performs at near Physical Raspberry Pi speeds, an instance running at 50% runs rightly at half that speed. This might be manageable under certain circumstances, but it’s not the most desirable. The overall efficiency of the cluster may increase, depending on the task at hand. But for now, we will continue with our original full core allocation of 3 nodes, and then later it tests with 6 nodes.
Single Thread Benchmarks
Testing can be done by using the following simple benchmark tests.
CPU Prime Test
sysbench --test=cpu --cpu-max-prime=9999 runCPU Integer Test
time $(i=0; while ((i<9999999)); do ((i++)); done)HDD Read Test
dd bs=16K count=102400 iflag=direct if=test_data of=/dev/nullHDD Write Test
dd bs=16k count=102400 oflag=direct if=/dev/zero of=test_dataResults (Single Thread)
For this guide, we will only focus on the CPU Prime Test using sysbench
Host
General statistics: total time: 10.0009s total number of events: 9417Latency (ms): min: 1.04 avg: 1.06 max: 1.63 95th percentile: 1.10 sum: 9992.36Threads fairness: events (avg/stddev): 9417.0000/0.00 execution time (avg/stddev): 9.9924/0.00Virtual Raspberry Pi – Limit: 100%
Test execution summary: total time: 397.8781s total number of events: 10000 total time taken by event execution: 397.4056 per-request statistics: min: 38.61ms avg: 39.74ms max: 57.15ms approx. 95 percentile: 40.92msThreads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 397.4056/0.00Virtual Raspberry Pi – Limit: 50%
Test execution summary: total time: 823.8272s total number of events: 10000 total time taken by event execution: 822.9329 per-request statistics: min: 38.68ms avg: 82.29ms max: 184.02ms approx. 95 percentile: 94.65msThreads fairness: events (avg/stddev): 10000.0000/0.00 execution time (avg/stddev): 822.9329/0.00Compose the Cluster
Create docker-compose.yml File
We will use Docker Compose for cluster creation. Initially, we will keep this at three nodes to keep it easy to manage. Once we have a proof of concept cluster, we can then scale it out. The most straightforward way to handle this is to map separate ports to localhost for each container. We can specify a range of ports to be used in the docker-compose.yml file, as noted below.
version: '3'services: node: image: pidoc ports: - "2201-2203:2222"Bring Up Cluster
To bring up three nodes with docker-compose, use the --scale option.
docker-compose up --scale node=3Ansible Configuration
Now that we have all the infrastructure in place for a cluster, we need to manage it. We could use Docker to double attach to the QEMU monitor, but ssh is much more robust. Since we are using ssh, we can use Ansible. A few basic operations are provided here: update, upgrade, reboot, and shutdown. These can be expanded as needed to develop a more robust system.
hosts File
Please note of the ports we specified in the docker-compose.yml file earlier, and edit your hosts inventory accordingly.
version: '3'services: node: image: pidoc ports: - "2201-2203:2222"For a more comprehensive walkthrough of Ansible, please read How to Install and Configure Ansible on Ubuntu.
update.yml File
---- name: Apt update Pi... hosts: pidoc-cluster tasks: - name: Update apt cache... become: yes apt: update_cache=yesUsage: ansible-playbook playbooks/update.yml -i hosts
upgrade.yml File
---- name: Upgrade Pi... hosts: pidoc-cluster gather_facts: no tasks: - name: Update and upgrade apt packages... become: true apt: upgrade: yes update_cache: yes cache_valid_time: 86400Usage: ansible-playbook playbooks/upgrade.yml -i hosts
reboot.yml File
---- name: Reboot Pi... hosts: pidoc-cluster gather_facts: no tasks: - name: Reboot Pi... shell: shutdown -r now async: 0 poll: 0 ignore_errors: true become: true - name: Wait for reboot... local_action: wait_for host={{ ansible_host }}state=started delay=10 become: falseUsage: ansible-playbook playbooks/reboot.yml -i hosts
shutdown.yml File
---- name: Shutdown Pi... hosts: pidoc-cluster gather_facts: no tasks: - name: 'Shutdown Pi' shell: shutdown -h now async: 0 poll: 0 ignore_errors: true become: true - name: "Wait for shutdown..." local_action: wait_for host={{ ansible_host }} state=stopped become: falseUsage: ansible-playbook playbooks/shutdown.yml -i hosts
Scaling Up
Docker Compose makes scaling Raspberry Pi containers on the same host near trivial. By using Ansible for cluster management, it also becomes incredibly easy to scale horizontally to other hosts by changing the port binding from localhost to an IP address that’s routable. Here is our example with 6 nodes instead of 3.
docker-compose.yml File
version: '3'services: node: image: pidoc ports: - "2201-2212:2222" deploy: resources: limits: cpus: "0.5"Bring Up Cluster
We should stop containers from our previous cluster, and prune all volumes before scaling up our revised cluster. To bring up all 6 nodes with docker-compose, use the --scale option again.
docker-compose up --scale node=5Future Work
Raspberry Pi emulation is still under development for QEMU. While the configuration for this project is relatively stable, there’s a lot of room for improvement. Attempting a migration to Raspberry Pi 3 emulation would be an ambitious next step. Docker Compose, though designed for single-host builds, is already easy enough to replicate to other hosts manually or through Ansible. But it could just as easily be scaled out with Swarm or k8s, enabling us to build an emulated Raspberry Pi cluster of any size. Additionally, with one or more port redirects, other systems of control can be put into place, including various node endpoints, depending on purpose and application.
Related articles
Query your cloud with natural language: A developer’s guide to Gcore MCP
What if you could ask your infrastructure questions and get real answers?With Gcore’s open-source implementation of the Model Context Protocol (MCP), now you can. MCP turns generative AI into an agent that understands your infrastructure, responds to your queries, and takes action when you need it to.In this post, we’ll demo how to use MCP to explore and inspect your Gcore environment just by prompting, to list resources, check audit logs, and generate cost reports. We’ll also walk through a fun bonus use case: provisioning infrastructure and exporting it to Terraform.What is MCP and why do devs love it?Originally developed by Anthropic, the Model Context Protocol (MCP) is an open standard that turns language models into agents that interact with structured tools: APIs, CLIs, or internal systems. Gcore’s implementation makes this protocol real for our customers.With MCP, you can:Ask questions about your infrastructureList, inspect, or filter cloud resourcesView cost data, audit logs, or deployment metadataExport configs to TerraformChain multi-step operations via natural languageGcore MCP removes friction from interacting with your infrastructure. Instead of wiring together scripts or context-switching across dashboards and CLIs, you can just…ask.That means:Faster debugging and auditsMore accessible infra visibilityFewer repetitive setup tasksBetter team collaborationBecause it’s open source, backed by the Gcore Python SDK, you can plug it into other APIs, extend tool definitions, or even create internal agents tailored to your stack. Explore the GitHub repo for yourself.What can you do with it?This isn’t just a cute chatbot. Gcore MCP connects your cloud to real-time insights. Here are some practical prompts you can use right away.Infrastructure inspection“List all VMs running in the Frankfurt region”“Which projects have over 80% GPU utilization?”“Show all volumes not attached to any instance”Audit and cost analysis“Get me the API usage for the last 24 hours”“Which users deployed resources in the last 7 days?”“Give a cost breakdown by region for this month”Security and governance“Show me firewall rules with open ports”“List all active API tokens and their scopes”Experimental automation“Create a secure network in Tokyo, export to Terraform, then delete it”We’ll walk through that last one in the full demo below.Full video demoWatch Gcore’s AI Software Engineer, Algis Dumbris, walk through setting up MCP on your machine and show off some use cases. If you prefer reading, we’ve broken down the process step-by-step below.Step-by-step walkthroughThis section maps to the video and shows exactly how to replicate the workflow locally.1. Install MCP locally (0:00–1:28)We use uv to isolate the environment and pull the project directly from GitHub.curl -Ls https://astral.sh/uv/install.sh | sh uvx add gcore-mcp-server https://github.com/G-Core/gcore-mcp-server Requirements:PythonGcore account + API keyTool config file (from the repo)2. Set up your environment (1:28–2:47)Configure two environment variables:GCORE_API_KEY for authGCORE_TOOLS to define what the agent can access (e.g., regions, instances, costs, etc.)Soon, tool selection will be automatic, but today you can define your toolset in YAML or JSON.3. Run a basic query (3:19–4:11)Prompt:“Find the Gcore region closest to Antalya.”The agent maps this to a regions.list call and returns: IstanbulNo need to dig through docs or write an API request.4. Provision, export, and clean up (4:19–5:32)This one’s powerful if you’re experimenting with CI/CD or infrastructure-as-code.Prompt:“Create a secure network in Tokyo. Export to Terraform. Then clean up.”The agent:Provisions the networkExports it to Terraform formatDestroys the resources afterwardYou get usable .tf output with no manual scripting. Perfect for testing, prototyping, or onboarding.Gcore: always building for developersTry it now:Clone the repoInstall UVX + configure your environmentStart prompting your infrastructureOpen issues, contribute tools, or share your use casesThis is early-stage software, and we’re just getting started. Expect more tools, better UX, and deeper integrations soon.Watch how easy it is to deploy an inference instance with Gcore
Cloud computing: types, deployment models, benefits, and how it works
Cloud computing is a model for enabling on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications, and services that can be rapidly provisioned and released with minimal management effort or service provider interaction. According to research by Gartner (2024), the global cloud computing market size is projected to reach $1.25 trillion by 2025, reflecting the rapid growth and widespread adoption of these services.The National Institute of Standards and Technology (NIST) defines five core characteristics that distinguish cloud computing from traditional IT infrastructure. These include on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.Each characteristic addresses specific business needs while enabling organizations to access computing resources without maintaining physical hardware on-premises.Cloud computing services are organized into three main categories that serve different business requirements and technical needs. Infrastructure as a Service (IaaS) provides basic computing resources, Platform as a Service (PaaS) offers development environments and tools, and Software as a Service (SaaS) delivers complete applications over the internet. Major cloud providers typically guarantee 99.9% or higher uptime in service level agreements to ensure reliable access to these services.Organizations can choose from four primary use models based on their security, compliance, and operational requirements. Public cloud services are offered over the internet to anyone, private clouds are proprietary networks serving limited users, hybrid clouds combine public and private cloud features, and community clouds serve specific groups with shared concerns. Each model provides different levels of control, security, and cost structures.Over 90% of enterprises use some form of cloud services as of 2024, according to Forrester Research (2024), making cloud computing knowledge important for modern business operations. This widespread adoption reflects how cloud computing has become a cornerstone of digital change and competitive advantage across industries.What is cloud computing?Cloud computing is a model that delivers computing resources like servers, storage, databases, and software over the internet on demand, allowing users to access and use these resources without owning or managing the physical infrastructure. Instead of buying and maintaining your own servers, you can rent computing power from cloud providers and scale resources up or down based on your needs.Over 90% of enterprises now use some form of cloud services, with providers typically guaranteeing 99.9% or higher uptime in their service agreements.The three main service models offer different levels of control and management. Infrastructure as a Service (IaaS) provides basic computing resources like virtual machines and storage. Platform as a Service (PaaS) adds development tools and runtime environments, and Software as a Service (SaaS) delivers complete applications that are ready to use. Each model handles different aspects of the technology stack, so you only manage what you need while the provider handles the rest.Cloud use models vary by ownership and access control. Public clouds serve multiple customers over the internet, private clouds operate exclusively for one organization, and hybrid clouds combine both approaches for flexibility. This variety lets organizations choose the right balance of cost, control, and security for their specific needs while maintaining the core benefits of cloud computing's flexible, elastic infrastructure.What are the main types of cloud computing services?The main types of cloud computing services refer to the different service models that provide computing resources over the internet with varying levels of management and control. The main types of cloud computing services are listed below.Infrastructure as a service (IaaS): This model provides basic computing infrastructure, including virtual machines, storage, and networking resources over the internet. Users can install and manage their own operating systems, applications, and development frameworks while the provider handles the physical hardware.Platform as a service (PaaS): This service offers a complete development and use environment in the cloud, including operating systems, programming languages, databases, and web servers. Developers can build, test, and use applications without managing the underlying infrastructure complexity.Software as a service (SaaS): This model delivers fully functional software applications over the internet through a web browser or mobile app. Users access the software on a subscription basis without needing to install, maintain, or update the applications locally.Function as a service (FaaS): Also known as serverless computing, this model allows developers to run individual functions or pieces of code in response to events. The cloud provider automatically manages server provisioning, scaling, and maintenance while charging only for actual compute time used.Database as a service (DBaaS): This service provides managed database solutions in the cloud, handling database administration tasks like backups, updates, and scaling. Organizations can access database functionality without maintaining physical database servers or hiring specialized database administrators.Storage as a service (STaaS): This model offers flexible cloud storage solutions for data backup, archiving, and file sharing needs. Users can store and retrieve data from anywhere with internet access while paying only for the storage space they actually use.What are the different cloud deployment models?Cloud use models refer to the different ways organizations can access and manage cloud computing resources based on ownership, location, and access control. The cloud use models are listed below.Public cloud: Services are delivered over the internet and shared among multiple organizations by third-party providers. Anyone can purchase and use these services on a pay-as-you-go basis, making them cost-effective for businesses without large upfront investments.Private cloud: Computing resources are dedicated to a single organization and can be hosted on-premises or by a third party. This model offers greater control, security, and customization options but requires higher costs and more management overhead.Hybrid cloud: Organizations combine public and private cloud environments, allowing data and applications to move between them as needed. This approach provides flexibility to keep sensitive data in private clouds while using public clouds for less critical workloads.Community cloud: Multiple organizations with similar requirements share cloud infrastructure and costs. Government agencies, healthcare organizations, or financial institutions often use this model to meet specific compliance and security standards.Multi-cloud: Organizations use services from multiple cloud providers to avoid vendor lock-in and improve redundancy. This plan allows businesses to choose the best services from different providers while reducing dependency on any single vendor.How does cloud computing work?Cloud computing works by delivering computing resources like servers, storage, databases, and software over the internet on an on-demand basis. Instead of owning physical hardware, users access these resources through web browsers or applications, while cloud providers manage the underlying infrastructure in data centers worldwide.The system operates through a front-end and back-end architecture. The front end includes your device, web browser, and network connection that you use to access cloud services.The back end consists of servers, storage systems, databases, and applications housed in the provider's data centers. When you request a service, the cloud infrastructure automatically allocates the necessary resources from its shared pool.The technology achieves its flexibility through virtualization, which creates multiple virtual instances from single physical servers. Resource pooling allows providers to serve multiple customers from the same infrastructure, while rapid elasticity automatically scales resources up or down based on demand.This elastic scaling can reduce resource costs by up to 30% compared to fixed infrastructure, according to McKinsey (2024), making cloud computing both flexible and cost-effective for businesses of all sizes.What are the key benefits of cloud computing?The key benefits of cloud computing refer to the advantages organizations and individuals gain from using internet-based computing services instead of traditional on-premises infrastructure. The key benefits of cloud computing are listed below.Cost reduction: Organizations eliminate upfront hardware investments and reduce ongoing maintenance expenses by paying only for resources they actually use. Cloud providers handle infrastructure management, reducing IT staffing costs and operational overhead.Flexibility and elasticity: Computing resources can expand or contract automatically based on demand, ensuring best performance during traffic spikes. This flexibility prevents over-provisioning during quiet periods and under-provisioning during peak usage.Improved accessibility: Users can access applications and data from any device with an internet connection, enabling remote work and global collaboration. This mobility supports modern work patterns and increases productivity across distributed teams.Enhanced reliability: Cloud providers maintain multiple data centers with redundant systems and backup infrastructure to ensure continuous service availability.Automatic updates and maintenance: Software updates, security patches, and system maintenance happen automatically without user intervention. This automation reduces downtime and ensures systems stay current with the latest features and security protections.Disaster recovery: Cloud services include built-in backup and recovery capabilities that protect against data loss from hardware failures or natural disasters. Recovery times are typically faster than traditional backup methods since data exists across multiple locations.Environmental effectiveness: Shared cloud infrastructure uses resources more effectively than individual company data centers, reducing overall energy consumption. Large cloud providers can achieve better energy effectiveness through economies of scale and advanced cooling technologies.What are the drawbacks and challenges of cloud computing?The drawbacks and challenges of cloud computing refer to the potential problems and limitations organizations may face when adopting cloud-based services. They are listed below.Security concerns: Organizations lose direct control over their data when it's stored on third-party servers. Data breaches, unauthorized access, and compliance issues become shared responsibilities between the provider and customer. Sensitive information may be vulnerable to cyber attacks targeting cloud infrastructure.Internet dependency: Cloud services require stable internet connections to function properly. Poor connectivity or outages can completely disrupt business operations and prevent access to critical applications. Remote locations with limited bandwidth face particular challenges accessing cloud resources.Vendor lock-in: Switching between cloud providers can be difficult and expensive due to proprietary technologies and data formats. Organizations may become dependent on specific platforms, limiting their flexibility to negotiate pricing or change services. Migration costs and technical complexity often discourage switching providers.Limited customization: Cloud services offer standardized solutions that may not meet specific business requirements. Organizations can't modify underlying infrastructure or install custom software configurations. This restriction can force businesses to adapt their processes to fit the cloud platform's limitations.Ongoing costs: Monthly subscription fees can accumulate to exceed traditional on-premise infrastructure costs over time. Unexpected usage spikes or data transfer charges can lead to budget overruns. Organizations lose the asset value that comes with owning physical hardware.Performance variability: Shared cloud resources can experience slower performance during peak usage periods. Network latency affects applications requiring real-time processing or frequent data transfers. Organizations can't guarantee consistent performance levels for mission-critical applications.Compliance complexity: Meeting regulatory requirements becomes more challenging when data is stored across multiple locations. Organizations must verify that cloud providers meet industry-specific compliance standards. Audit trails and data governance become shared responsibilities that require careful coordination.Gcore Edge CloudWhen building AI applications that require serious computational power, the infrastructure you choose can make or break your project's success. Whether you're training large language models, running complex inference workloads, or tackling high-performance computing challenges, having access to the latest GPU technology without performance bottlenecks becomes critical.Gcore's AI GPU Cloud Infrastructure addresses these demanding requirements with bare metal NVIDIA H200. H100. A100. L40S, and GB200 GPUs, delivering zero virtualization overhead for maximum performance. The platform's ultra-fast InfiniBand networking and multi-GPU cluster support make it particularly well-suited for distributed training and large-scale AI workloads, starting from just €1.25/hour. Multi-instance GPU (MIG) support also allows you to improve resource allocation and costs for smaller inference tasks.Discover how Gcore's bare metal GPU performance can accelerate your AI training and inference workloads at https://gcore.com/gpu-cloud.Frequently asked questionsPeople often have questions about cloud computing basics, costs, and how it fits their specific needs. These answers cover the key service models, use options, and practical considerations that help clarify what cloud computing can do for your organization.What's the difference between cloud computing and traditional hosting?Cloud computing delivers resources over the internet on demand, while traditional hosting provides fixed server resources at dedicated locations. Cloud offers elastic growth and pay-as-you-go pricing, whereas traditional hosting requires upfront capacity planning and fixed costs regardless of actual usage.What is cloud computing security?Cloud computing security protects data, applications, and infrastructure in cloud environments through shared responsibility models between providers and users. Cloud providers secure the underlying infrastructure while users protect their data, applications, and access controls.What is virtualization in cloud computing?Virtualization in cloud computing creates multiple virtual machines (VMs) on a single physical server using hypervisor software that separates computing resources. This technology allows cloud providers to increase hardware effectiveness and offer flexible, isolated environments to multiple users simultaneously.Is cloud computing secure for business data?Yes, cloud computing is secure for business data when proper security measures are in place, with major providers offering encryption, access controls, and compliance certifications that often exceed what most businesses can achieve on-premises. Cloud service providers typically guarantee 99.9% or higher uptime in service level agreements while maintaining enterprise-grade security standards.How much does cloud computing cost compared to on-premises infrastructure?Cloud computing typically costs 20-40% less than on-premises infrastructure due to shared resources, reduced hardware purchases, and lower maintenance expenses, according to IDC (2024). However, costs vary primarily based on usage patterns, with predictable workloads sometimes being cheaper on-premises while variable workloads benefit more from cloud's pay-as-you-go model.How do I choose between IaaS, PaaS, and SaaS?Choose based on your control needs. IaaS gives you full infrastructure control, PaaS handles infrastructure so you focus on development, and SaaS provides ready-to-use applications with no technical management required.
Pre-configure your dev environment with Gcore VM init scripts
Provisioning new cloud instances can be repetitive and time-consuming if you’re doing everything manually: installing packages, configuring environments, copying SSH keys, and more. With cloud-init, you can automate these tasks and launch development-ready instances from the start.Gcore Edge Cloud VMs support cloud-init out of the box. With a simple YAML script, you can automatically set up a development-ready instance at boot, whether you’re launching a single machine or spinning up a fleet.In this guide, we’ll walk through how to use cloud-init on Gcore Edge Cloud to:Set a passwordInstall packages and system updatesAdd users and SSH keysMount disks and write filesRegister services or install tooling like Docker or Node.jsLet’s get started.What is cloud-init?cloud-init is a widely used tool for customizing cloud instances during the first boot. It reads user-provided configuration data—usually YAML—and uses it to run commands, install packages, and configure the system. In this article, we will focus on Linux-based virtual machines.How to use cloud-init on GcoreFor Gcore Cloud VMs, cloud-init scripts are added during instance creation using the User data field in the UI or API.Step 1: Create a basic scriptStart with a simple YAML script. Here’s one that updates packages and installs htop:#cloud-config package_update: true packages: - htop Step 2: Launch a new VM with your scriptGo to the Gcore Customer Portal, navigate to VMs, and start creating a new instance (or just click here). When you reach the Additional options section, enable the User data option. Then, paste in your YAML cloud-init script.Once the VM boots, it will automatically run the script. This works the same way for all supported Linux distributions available through Gcore.3 real-world examplesLet’s look at three examples of how you can use this.Example 1: Add a password for a specific userThe below script sets the for the default user of the selected operating system:#cloud-config password: <password> chpasswd: {expire: False} ssh_pwauth: True Example 2: Dev environment with Docker and GitThe following script does the following:Installs Docker and GitAdds a new user devuser with sudo privilegesAuthorizes an SSH keyStarts Docker at boot#cloud-config package_update: true packages: - docker.io - git users: - default - name: devuser sudo: ALL=(ALL) NOPASSWD:ALL groups: docker shell: /bin/bash ssh-authorized-keys: - ssh-rsa AAAAB3Nza...your-key-here runcmd: - systemctl enable docker - systemctl start docker Example 3: Install Node.js and clone a repoThis script installs Node.js and clones a GitHub repo to your Gcore VM at launch:#cloud-config packages: - curl runcmd: - curl -fsSL https://deb.nodesource.com/setup_18.x | bash - - apt-get install -y nodejs - git clone https://github.com/example-user/dev-project.git /home/devuser/project Reusing and versioning your scriptsTo avoid reinventing the wheel, keep your cloud-init scripts:In version control (e.g., Git)Templated for different environments (e.g., dev vs staging)Modular so you can reuse base blocks across projectsYou can also use tools like Ansible or Terraform with cloud-init blocks to standardize provisioning across your team or multiple Gcore VM environments.Debugging cloud-initIf your script doesn’t behave as expected, SSH into the instance and check the cloud-init logs:sudo cat /var/log/cloud-init-output.log This file shows each command as it ran and any errors that occurred.Other helpful logs:/var/log/cloud-init.log /var/lib/cloud/instance/user-data.txt Pro tip: Echo commands or write log files in your script to help debug tricky setups—especially useful if you’re automating multi-node workflows across Gcore Cloud.Tips and best practicesIndentation matters! YAML is picky. Use spaces, not tabs.Always start the file with #cloud-config.runcmd is for commands that run at the end of boot.Use write_files to write configs, env variables, or secrets.Cloud-init scripts only run on the first boot. To re-run, you’ll need to manually trigger cloud-init or re-create the VM.Automate it all with GcoreIf you're provisioning manually, you're doing it wrong. Cloud-init lets you treat your VM setup as code: portable, repeatable, and testable. Whether you’re spinning up ephemeral dev boxes or preparing staging environments, Gcore’s support for cloud-init means you can automate it all.For more on managing virtual machines with Gcore, check out our product documentation.Explore Gcore VM product docs
How to cut egress costs and speed up delivery using Gcore CDN and Object Storage
If you’re serving static assets (images, videos, scripts, downloads) from object storage, you’re probably paying more than you need to, and your users may be waiting longer than they should.In this guide, we explain how to front your bucket with Gcore CDN to cache static assets, cut egress bandwidth costs, and get faster TTFB globally. We’ll walk through setup (public or private buckets), signed URL support, cache control best practices, debugging tips, and automation with the Gcore API or Terraform.Why bother?Serving directly from object storage hits your origin for every request and racks up egress charges. With a CDN in front, cached files are served from edge—faster for users, and cheaper for you.Lower TTFB, better UXWhen content is cached at the edge, it doesn’t have to travel across the planet to get to your user. Gcore CDN caches your assets at PoPs close to end users, so requests don’t hit origin unless necessary. Once cached, assets are delivered in a few milliseconds.Lower billsMost object storage providers charge $80–$120 per TB in egress fees. By fronting your storage with a CDN, you only pay egress once per edge location—then it’s all cache hits after that. If you’re using Gcore Storage and Gcore CDN, there’s zero egress fee between the two.Caching isn’t the only way you save. Gcore CDN can also compress eligible file types (like HTML, CSS, JavaScript, and JSON) on the fly, further shrinking bandwidth usage and speeding up file delivery—all without any changes to your storage setup.Less origin traffic and less data to transfer means smaller bills. And your storage bucket doesn’t get slammed under load during traffic spikes.Simple scaling, globallyThe CDN takes the hit, not your bucket. That means fewer rate-limit issues, smoother traffic spikes, and more reliable performance globally. Gcore CDN spans the globe, so you’re good whether your users are in Tokyo, Toronto, or Tel Aviv.Setup guide: Gcore CDN + Gcore Object StorageLet’s walk through configuring Gcore CDN to cache content from a storage bucket. This works with Gcore Object Storage and other S3-compatible services.Step 1: Prep your bucketPublic? Check files are publicly readable (via ACL or bucket policy).Private? Use Gcore’s AWS Signature V4 support—have your access key, secret, region, and bucket name ready.Gcore Object Storage URL format: https://<bucket-name>.<region>.cloud.gcore.lu/<object> Step 2: Create CDN resource (UI or API)In the Gcore Customer Portal:Go to CDN > Create CDN ResourceChoose "Accelerate and protect static assets"Set a CNAME (e.g. cdn.yoursite.com) if you want to use your domainConfigure origin:Public bucket: Choose None for authPrivate bucket: Choose AWS Signature V4, and enter credentialsChoose HTTPS as the origin protocolGcore will assign a *.gcdn.co domain. If you’re using a custom domain, add a CNAME: cdn.yoursite.com CNAME .gcdn.co Here’s how it works via Terraform: resource "gcore_cdn_resource" "cdn" { cname = "cdn.yoursite.com" origin_group_id = gcore_cdn_origingroup.origin.id origin_protocol = "HTTPS" } resource "gcore_cdn_origingroup" "origin" { name = "my-origin-group" origin { source = "mybucket.eu-west.cloud.gcore.lu" enabled = true } } Step 3: Set caching behaviorSet Cache-Control headers in your object metadata: Cache-Control: public, max-age=2592000 Too messy to handle in storage? Override cache logic in Gcore:Force TTLs by path or extensionIgnore or forward query strings in cache keyStrip cookies (if unnecessary for cache decisions)Pro tip: Use versioned file paths (/img/logo.v3.png) to bust cache safely.Secure access with signed URLsWant your assets to be private, but still edge-cacheable? Use Gcore’s Secure Token feature:Enable Secure Token in CDN settingsSet a secret keyGenerate time-limited tokens in your appPython example: import base64, hashlib, time secret = 'your_secret' path = '/videos/demo.mp4' expires = int(time.time()) + 3600 string = f"{expires}{path} {secret}" token = base64.urlsafe_b64encode(hashlib.md5(string.encode()).digest()).decode().strip('=') url = f"https://cdn.yoursite.com{path}?md5={token}&expires={expires}" Signed URLs are verified at the CDN edge. Invalid or expired? Blocked before origin is touched.Optional: Bind the token to an IP to prevent link sharing.Debug and cache tuneUse curl or browser devtools: curl -I https://cdn.yoursite.com/img/logo.png Look for:Cache: HIT or MISSCache-ControlX-Cached-SinceCache not working? Check for the following errors:Origin doesn’t return Cache-ControlCDN override TTL not appliedCache key includes query strings unintentionallyYou can trigger purges from the Gcore Customer Portal or automate them via the API using POST /cdn/purge. Choose one of three ways:Purge all: Clear the entire domain’s cache at once.Purge by URL: Target a specific full path (e.g., /images/logo.png).Purge by pattern: Target a set of files using a wildcard at the end of the pattern (e.g., /videos/*).Monitor and optimize at scaleAfter rollout:Watch origin bandwidth dropCheck hit ratio (aim for >90%)Audit latency (TTFB on HIT vs MISS)Consider logging using Gcore’s CDN logs uploader to analyze cache behavior, top requested paths, or cache churn rates.For maximum savings, combine Gcore Object Storage with Gcore CDN: egress traffic between them is 100% free. That means you can serve cached assets globally without paying a cent in bandwidth fees.Using external storage? You’ll still slash egress costs by caching at the edge and cutting direct origin traffic—but you’ll unlock the biggest savings when you stay inside the Gcore ecosystem.Save money and boost performance with GcoreStill serving assets direct from storage? You’re probably wasting money and compromising performance on the table. Front your bucket with Gcore CDN. Set smart cache headers or use overrides. Enable signed URLs if you need control. Monitor cache HITs and purge when needed. Automate the setup with Terraform. Done.Next steps:Create your CDN resourceUse private object storage with Signature V4Secure your CDN with signed URLsCreate a free CDN resource now
Bare metal vs. virtual machines: performance, cost, and use case comparison
Choosing the right type of server infrastructure is critical to how your application performs, scales, and fits your budget. For most workloads, the decision comes down to two core options: bare metal servers and cloud virtual machines (VMs). Both can be deployed in the cloud, but they differ significantly in terms of performance, control, scalability, and cost.In this article, we break down the core differences between bare metal and virtual servers, highlight when to choose each, and explain how Gcore can help you deploy the right infrastructure for your needs. If you want to learn about either BM or VMs in detail, we’ve got articles for those: here’s the one for bare metal, and here’s a deep dive into virtual machines.Bare metal vs. virtual machines at a glanceWhen evaluating whether bare metal or virtual machines are right for your company, consider your specific workload requirements, performance priorities, and business objectives. Here’s a quick breakdown to help you decide what works best for you.FactorBare metal serversVirtual machinesPerformanceDedicated resources; ideal for high-performance workloadsShared resources; suitable for moderate or variable workloadsScalabilityOften requires manual scaling; less flexibleHighly elastic; easy to scale up or downCustomizationFull control over hardware, OS, and configurationLimited by hypervisor and provider’s environmentSecurityIsolated by default; no hypervisor layerShared environment with strong isolation protocolsCostHigher upfront cost; dedicated hardwarePay-as-you-go pricing; cost-effective for flexible workloadsBest forHPC, AI/ML, compliance-heavy workloadsStartups, dev/test, fast-scaling applicationsAll about bare metal serversA bare metal server is a single-tenant physical server rented from a cloud provider. Unlike virtual servers, the hardware is not shared with other users, giving you full access to all resources and deeper control over configurations. You get exclusive access and control over the hardware via the cloud provider, which offers the stability and security needed for high-demand applications.The benefits of bare metal serversHere are some of the business advantages of opting for a bare metal server:Maximized performance: Because they are dedicated resources, bare metal servers provide top-tier performance without sharing processing power, memory, or storage with other users. This makes them ideal for resource-intensive applications like high-performance computing (HPC), big data processing, and game hosting.Greater control: Since you have direct access to the hardware, you can customize the server to meet your specific requirements. This is especially important for businesses with complex, specialized needs that require fine-tuned configurations.High security: Bare metal servers offer a higher level of security than their alternatives due to the absence of virtualization. With no shared resources or hypervisor layer, there’s less risk of vulnerabilities that come with multi-tenant environments.Dedicated resources: Because you aren’t sharing the server with other users, all server resources are dedicated to your application so that you consistently get the performance you need.Who should use bare metal servers?Here are examples of instances where bare metal servers are the best option for a business:High-performance computing (HPC)Big data processing and analyticsResource-intensive applications, such as AI/ML workloadsGame and video streaming serversBusinesses requiring enhanced security and complianceAll about virtual machinesA virtual server (or virtual machine) runs on top of a physical server that’s been partitioned by a cloud provider using a hypervisor. This allows multiple VMs to share the same hardware while remaining isolated from each other.Unlike bare metal servers, virtual machines share the underlying hardware with other cloud provider customers. That means you’re using (and paying for) part of one server, providing cost efficiency and flexibility.The benefits of virtual machinesHere are some advantages of using a shared virtual machine:Scalability: Virtual machines are ideal for businesses that need to scale quickly and are starting at a small scale. With cloud-based virtualization, you can adjust your server resources (CPU, memory, storage) on demand to match changing workloads.Cost efficiency: You pay only for the resources you use with VMs, making them cost-effective for companies with fluctuating resource needs, as there is no need to pay for unused capacity.Faster deployment: VMs can be provisioned quickly and easily, which makes them ideal for anyone who wants to deploy new services or applications fast.Who should use virtual machines?VMs are a great fit for the following:Web hosting and application hostingDevelopment and testing environmentsRunning multiple apps with varying demandsStartups and growing businesses requiring scalabilityBusinesses seeking cost-effective, flexible solutionsWhich should you choose?There’s no one-size-fits-all answer. Your choice should depend on the needs of your workload:Choose bare metal if you need dedicated performance, low-latency access to hardware, or tighter control over security and compliance.Choose virtual servers if your priority is flexible scaling, faster deployment, and optimized cost.If your application uses GPU-based inference or AI training, check out our dedicated guide to VM vs. BM for AI workloads.Get started with Gcore BM or VMs todayAt Gcore, we provide both bare metal and virtual machine solutions, offering flexibility, performance, and reliability to meet your business needs. Gcore Bare Metal has the power and reliability needed for demanding workloads, while online virtual machines offers customizable configurations, free egress traffic, and flexibility.Compare Gcore BM and VM pricing now
Optimize your workload: a guide to selecting the best virtual machine configuration
Virtual machines (VMs) offer the flexibility, scalability, and cost-efficiency that businesses need to optimize workloads. However, choosing the wrong setup can lead to poor performance, wasted resources, and unnecessary costs.In this guide, we’ll walk you through the essential factors to consider when selecting the best virtual machine configuration for your specific workload needs.﹟1 Understand your workload requirementsThe first step in choosing the right virtual machine configuration is understanding the nature of your workload. Workloads can range from light, everyday tasks to resource-intensive applications. When making your decision, consider the following:Compute-intensive workloads: Applications like video rendering, scientific simulations, and data analysis require a higher number of CPU cores. Opt for VMs with multiple processors or CPUs for smoother performance.Memory-intensive workloads: Databases, big data analytics, and high-performance computing (HPC) jobs often need more RAM. Choose a VM configuration that provides sufficient memory to avoid memory bottlenecks.Storage-intensive workloads: If your workload relies heavily on storage, such as file servers or applications requiring frequent read/write operations, prioritize VM configurations that offer high-speed storage options, such as SSDs or NVMe.I/O-intensive workloads: Applications that require frequent network or disk I/O, such as cloud services and distributed applications, benefit from VMs with high-bandwidth and low-latency network interfaces.﹟2 Consider VM size and scalabilityOnce you understand your workload’s requirements, the next step is to choose the right VM size. VM sizes are typically categorized by the amount of CPU, memory, and storage they offer.Start with a baseline: Select a VM configuration that offers a balanced ratio of CPU, RAM, and storage based on your workload type.Scalability: Choose a VM size that allows you to easily scale up or down as your needs change. Many cloud providers offer auto-scaling capabilities that adjust your VM’s resources based on real-time demand, providing flexibility and cost savings.Overprovisioning vs. underprovisioning: Avoid overprovisioning (allocating excessive resources) unless your workload demands peak capacity at all times, as this can lead to unnecessary costs. Similarly, underprovisioning can affect performance, so finding the right balance is essential.﹟3 Evaluate CPU and memory considerationsThe central processing unit (CPU) and memory (RAM) are the heart of a virtual machine. The configuration of both plays a significant role in performance. Workloads that need high processing power, such as video encoding, machine learning, or simulations, will benefit from VMs with multiple CPU cores. However, be mindful of CPU architecture—look for VMs that offer the latest processors (e.g., Intel Xeon, AMD EPYC) for better performance per core.It’s also important that the VM has enough memory to avoid paging, which occurs when the system uses disk space as virtual memory, significantly slowing down performance. Consider a configuration with more RAM and support for faster memory types like DDR4 for memory-heavy applications.﹟4 Assess storage performance and capacityStorage performance and capacity can significantly impact the performance of your virtual machine, especially for applications requiring large data volumes. Key considerations include:Disk type: For faster read/write operations, opt for solid-state drives (SSDs) over traditional hard disk drives (HDDs). Some cloud providers also offer NVMe storage, which can provide even greater speed for highly demanding workloads.Disk size: Choose the right size based on the amount of data you need to store and process. Over-allocating storage space might seem like a safe bet, but it can also increase costs unnecessarily. You can always resize disks later, so avoid over-allocating them upfront.IOPS and throughput: Some workloads require high input/output operations per second (IOPS). If this is a priority for your workload (e.g., databases), make sure that your VM configuration includes high IOPS storage options.﹟5 Weigh up your network requirementsWhen working with cloud-based VMs, network performance is a critical consideration. High-speed and low-latency networking can make a difference for applications such as online gaming, video conferencing, and real-time analytics.Bandwidth: Check whether the VM configuration offers the necessary bandwidth for your workload. For applications that handle large data transfers, such as cloud backup or file servers, make sure that the network interface provides high throughput.Network latency: Low latency is crucial for applications where real-time performance is key (e.g., trading systems, gaming). Choose VMs with low-latency networking options to minimize delays and improve the user experience.Network isolation and security: Check if your VM configuration provides the necessary network isolation and security features, especially when handling sensitive data or operating in multi-tenant environments.﹟6 Factor in cost considerationsWhile it’s essential that your VM has the right configuration, cost is always an important factor to consider. Cloud providers typically charge based on the resources allocated, so optimizing for cost efficiency can significantly impact your budget.Consider whether a pay-as-you-go or reserved model (which offers discounted rates in exchange for a long-term commitment) fits your usage pattern. The reserved option can provide significant savings if your workload runs continuously. You can also use monitoring tools to track your VM’s performance and resource usage over time. This data will help you make informed decisions about scaling up or down so you’re not paying for unused resources.﹟7 Evaluate security featuresSecurity is a primary concern when selecting a VM configuration, especially for workloads handling sensitive data. Consider the following:Built-in security: Look for VMs that offer integrated security features such as DDoS protection, WAAP security, and encryption.Compliance: Check that the VM configuration meets industry standards and regulations, such as GDPR, ISO 27001, and PCI DSS.Network security: Evaluate the VM's network isolation capabilities and the availability of cloud firewalls to manage incoming and outgoing traffic.﹟8 Consider geographic locationThe geographic location of your VM can impact latency and compliance. Therefore, it’s a good idea to choose VM locations that are geographically close to your end users to minimize latency and improve performance. In addition, it’s essential to select VM locations that comply with local data sovereignty laws and regulations.﹟9 Assess backup and recovery optionsBackup and recovery are critical for maintaining data integrity and availability. Look for VMs that offer automated backup solutions so that data is regularly saved. You should also evaluate disaster recovery capabilities, including the ability to quickly restore data and applications in case of failure.﹟10 Test and iterateFinally, once you've chosen a VM configuration, testing its performance under real-world conditions is essential. Most cloud providers offer performance monitoring tools that allow you to assess how well your VM is meeting your workload requirements.If you notice any performance bottlenecks, be prepared to adjust the configuration. This could involve increasing CPU cores, adding more memory, or upgrading storage. Regular testing and fine-tuning means that your VM is always optimized.Choosing a virtual machine that suits your requirementsSelecting the best virtual machine configuration is a key step toward optimizing your workloads efficiently, cost-effectively, and without unnecessary performance bottlenecks. By understanding your workload’s needs, considering factors like CPU, memory, storage, and network performance, and continuously monitoring resource usage, you can make informed decisions that lead to better outcomes and savings.Whether you're running a small application or large-scale enterprise software, the right VM configuration can significantly improve performance and cost. Gcore provides flexible online virtual machine options that can meet your unique requirements. Our virtual machines are designed to meet diverse workload requirements, providing dedicated vCPUs, high-speed storage, and low-latency networking across 30+ global regions. You can scale compute resources on demand, benefit from free egress traffic, and enjoy flexible pricing models by paying only for the resources in use, maximizing the value of your cloud investments.Contact us to discuss your VM needs
Subscribe to our newsletter
Get the latest industry trends, exclusive insights, and Gcore updates delivered straight to your inbox.