Providers

Providers are added when the environment is created and can be modified at any time.

An environment can contain zero or more providers. A provider enables the deployment of instances on various cloud platforms by acting as a connector between LayerOps and your cloud infrastructure.

Key Concepts

Platform Connectivity
Each provider is associated with a specific cloud platform (e.g., Amazon Web Services, Microsoft Azure, Google Cloud Platform). This connection allows you to deploy and manage resources on these platforms through LayerOps.

Region Selection
When configuring a provider, you specify the region within the cloud platform where your resources will be deployed. This allows you to optimize for latency and comply with data residency requirements.

Credential Management
Providers use platform access credentials (such as access keys or authentication tokens) to interact with your cloud platform. These credentials are securely stored and managed through LayerOps' platform access feature.

Managing Providers

You can manage your providers directly from your environment dashboard. The example below shows an environment with Azure, Exoscale and OVH providers:

edit providers

Click the "Edit" button to add new providers or remove existing ones from your environment.

All environments support external hosts, regardless of whether you have configured any providers. This allows you to integrate existing infrastructure with LayerOps.

Using Providers

When creating an instance pool later, you'll need to choose which provider to use for deploying your instances. You can either:

  • Select one of your configured cloud providers to deploy new instances
  • Create an external host to connect an existing dedicated server or VM to your environment

See Instance Pools for more details about instance creation and management.

LXD Considerations

You can use a remote lxd server as provider as soon as it meets following requirements:

Below is an installation script that helps you set up and configure LXD server with proper security settings and SSL certificates:

#!/bin/bash

# Variables
DOMAIN="your-domain.com"
EMAIL="your-email@example.com"
CERT_DIR="/var/snap/lxd/common/lxd"
CERT_PATH="/etc/letsencrypt/live/$DOMAIN/fullchain.pem"
PRIVKEY_PATH="/etc/letsencrypt/live/$DOMAIN/privkey.pem"

# List of allowed IP addresses
ALLOWED_SSH_IPS=("192.0.2.1" "198.51.100.1")  # Replace with the IP addresses you want to allow for SSH
ALLOWED_8443_IPS=("212.129.25.20" "51.159.95.50")  # IP list provided by LayerOps - contact support

# Check root permissions
if [ "$EUID" -ne 0 ]; then
  echo "Please run this script as root."
  exit 1
fi

# Verify that the domain name points to the server's public IP address
PUBLIC_IP=$(curl -s ifconfig.me)
DOMAIN_IP=$(dig +short $DOMAIN)

if [ "$PUBLIC_IP" != "$DOMAIN_IP" ]; then
  echo "The domain $DOMAIN does not point to the server's public IP address ($PUBLIC_IP)."
  exit 1
fi

# System update and dependencies installation
apt update
apt upgrade -y
apt install -y snapd ufw dnsutils curl cron

# Install LXD via Snap
snap install lxd
/snap/bin/lxd init --auto

# Install Certbot
snap install core; snap refresh core
snap install --classic certbot
ln -s /snap/bin/certbot /usr/bin/certbot

# Check if SSL certificate already exists
if [ -f "$CERT_PATH" ] && [ -f "$PRIVKEY_PATH" ]; then
  echo "SSL certificate already exists. No generation needed."
else
  # Get SSL certificate with Certbot (HTTP process in background)
  certbot certonly --standalone --preferred-challenges http -d $DOMAIN --email $EMAIL --agree-tos --non-interactive &
  
  # Wait for certificate generation
  wait

  # Verify that certificates were generated
  if [ ! -f "$CERT_PATH" ] || [ ! -f "$PRIVKEY_PATH" ]; then
    echo "Certificate generation failed. Check Certbot logs for more details."
    exit 1
  fi
fi

# Configure LXD to use SSL certificate
cp "$CERT_PATH" $CERT_DIR/server.crt
cp "$PRIVKEY_PATH" $CERT_DIR/server.key

# Modify LXD configuration to use SSL
lxc config set core.https_address ":8443"

# Restart LXD to apply changes
systemctl restart snap.lxd.daemon

# Configure UFW firewall
ufw default deny incoming
ufw default allow outgoing
ufw allow from any to any port 80,443 proto tcp  # Allow HTTP/HTTPS for Certbot
ufw allow from any to any port 22 proto tcp  # Allow SSH from everywhere temporarily
ufw allow in on lxdbr0
ufw route allow in on lxdbr0
ufw route allow out on lxdbr0

# Allow only specified IP addresses for SSH
for ip in "${ALLOWED_SSH_IPS[@]}"; do
  ufw allow from $ip to any port 22 proto tcp
done

# Allow only specified IP addresses for port 8443
for ip in "${ALLOWED_8443_IPS[@]}"; do
  ufw allow from $ip to any port 8443 proto tcp
done

# Enable UFW
ufw enable

# Remove global SSH rules for better security
ufw delete allow 22/tcp

# Configure cron job to automatically renew SSL certificate
(crontab -l 2>/dev/null; echo "0 0 * * * /usr/bin/certbot renew --post-hook 'cp /etc/letsencrypt/live/$DOMAIN/fullchain.pem $CERT_DIR/server.crt && cp /etc/letsencrypt/live/$DOMAIN/privkey.pem $CERT_DIR/server.key && systemctl restart snap.lxd.daemon'") | crontab -
  • To allow volume quotas on dir storage driver, the default "storage-pools" directory (/var/snap/lxd/common/lxd/storage-pools if installed via snap) must be within a xfs partition mounted with project quota enabled (see documentation ). Example using ubuntu server:
# Install quotas:
apt install quota

# Add Mount Point
MOUNT_DEVICE= # Partition to mount storage pool to
cat >> /etc/fstab <<EOF
$MOUNT_DEVICE /var/snap/lxd/common/lxd/storage-pools xfs defaults,prjquota 0 0
EOF

# Mount storage pools:
mount /var/snap/lxd/common/lxd/storage-pools
Table of Contents