Automation plays a key role in standardising and simplifying the process of building environments.

Continuing on my journey of automating my home lab setup, I found a very good resource that’s available for Proxmox users to automate the installation of various Linux containers and Virtual Machines. You can find them from user tteckster here https://tteck.github.io/Proxmox/

By using these scripts, we can save time, ensure consistency, and reduce the chances of human error during the environment build process.

Why Automate LXC and VM Builds?

Automation offers several notable benefits when it comes to building Linux containers and VMs:

Time and Effort Savings

Manually configuring and setting up containers or VMs can be a time-consuming and labor-intensive task.

By automating the build process using command line scripts, we can save significant time and effort.

Scripts eliminate the need to manually perform repetitive steps, allowing for faster deployment.

Consistency and Reproducibility

Maintaining consistency across multiple containers or VMs is vital in ensuring reliable application deployment.

Command line scripts enable us to define the exact configuration and settings required for each container or VM.

By automating the build process, every instance is built using the same steps, ensuring consistency and reproducibility across different environments.

Error Reduction

Manual configuration is prone to human error. Even a small mistake in the build process can lead to significant issues, affecting the stability and performance.

Automation minimises the chances of human error by executing a predefined set of instructions consistently.

Scripts can perform complex and error-prone tasks accurately, reducing the risk of misconfiguration or missteps.

Flexibility and Customisation

These command line scripts provide a flexible and customisable approach to building Linux containers and VMs.

These scripts often offer various options and parameters that allow us to tailor the build process according to their specific requirements.

We can choose different configurations, select specific software packages, and define resource allocation based on our application’s needs.

Introducing the Command Line Scripts

This brilliant website by tteckster provides a collection of command line scripts that enable the automation of Linux Container (LXC) and Virtual Machine (VM) builds on Proxmox.

These scripts enable us to create in an interactive manner, offering options for both basic and advanced configurations.

Basic Setup

The basic setup uses default settings, making it a convenient option for users who prefer a quick and straight forward setup.

To run the basic script for your specific machine, go through the list of options available and use the command in the Proxmox shell.

For example, to create a Linux Container for Cloudflared, we can use the following command:

bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/ct/cloudflared.sh)"

Or to create a MariaDB container, we can use the following command:

bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/ct/mariadb.sh)"

Advanced Setup

For more flexibility and customisation, the advanced setup feature of the scripts allows us to alter the default settings according to our needs.

This function utilises the whiptail command to present options in a dialogue box format, allowing us to modify the options available, such as increased memory, disk size and set options such as static IP addresses and DNS.

To run the advanced setup script, when prompted, choose the settings options when presented after running your chosen script.

After selecting your options, the script collects and verifies the input in order to generate the final configuration for the container or virtual machine.

Summary

Automating our Proxmox builds with command line scripts streamlines the deployment process, reduces manual effort, and ensures consistency and reproducibility.

By using the provided basic or advanced setup scripts from the website, we can easily build Linux Containers or Virtual Machines on Proxmox tailored to our specific needs in a repeatable manner.

Remember to visit https://tteck.github.io/Proxmox/ for more details and documentation on the available scripts.

There are also a number of other scripts available and can be found by searching on GitHub. For example, user roib20 has created Proxmox helper scripts for TrueNAS and CloudInit which can be found here https://github.com/roib20/proxmox-scripts

These days, optimising workflows and automating processes is key to efficient software development and infrastructure management.

In my previous posts I covered how to configure Drone to build Hugo and deploy to various destinations, such as an FTP / Web server or Cloudflare Pages.

As I’ve been using and learning more about Hugo, I noticed that the Docker Image I was using to build my Hugo files in Drone was quite out of date and wouldn’t let me use some of the latest features available. After a brief search on the web, I couldn’t find a more recent version.

So, with a couple of spare hours on a Saturday morning, I did some research and looked in to building my own Docker Image and have it published to GitHub’s Container Registry.

And we now have the andrewbeaton/hugo-drone Docker image.

What is it?

andrewbeaton/hugo-drone is a Docker image specifically designed to facilitate Hugo site builds and deployments.

Built upon the popular Drone CI/CD platform, this image contains a preconfigured environment with Hugo and other necessary dependencies, aiming to streamline the setup process and ensuring consistency across different development environments.

The image is based on RockyLinux and installs the current version of Hugo, which is currently v0.113.0.

My aim is to build and release a new versioned image, for each major release that comes along.

Step 1: Installing Docker

Before we can use andrewbeaton/hugo-drone, we need to have Docker installed on our system. Docker allows us to run containers, which are lightweight, isolated environments that encapsulate our applications and their dependencies. Follow these instructions to install Docker on your operating system.

Step 2: Pulling the Image

Once Docker is installed, we can pull the andrewbeaton/hugo-drone image from the GitHub Images Repository.

Open your terminal or command prompt and enter the following command:

docker pull ghcr.io/andrewbeaton/hugo-drone:latest

This command will fetch the latest version of the image and make it available on your system for usage.

Step 3: Creating a Hugo Project

To work with andrewbeaton/hugo-drone, you need to have an existing Hugo project or create a new one.

If you haven’t set up a Hugo project yet, follow these steps:

1. Install Hugo:
   Visit the official Hugo website and download the appropriate binary for your operating system. Follow the installation instructions provided.

2. Create a New Hugo Site:
   In your terminal or command prompt, navigate to your desired project directory and run the following command:

   hugo new site my-hugo-site
   

   This command will create a new Hugo site with the name “my-hugo-site” in the current directory.

3. Add a Theme:
   Navigate to your Hugo site’s directory and add a theme of your choice. You can explore various themes on the Hugo Themes website or use a specific theme by following its documentation.

Step 4: Setting Up a Drone Configuration File

Drone relies on a configuration file named .drone.yml to define the build pipeline.

Create a new file named .drone.yml in the root of your Hugo project and add the following content as a starting point:

kind: pipeline
type: docker
name: default

steps:
  - name: Build with Hugo
    image: ghcr.io/andrewbeaton/hugo-drone:latest
    pull: always
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment production --verbose --debug 
      - ls -al /drone/src/hugo/public

This configuration instructs Drone to use the andrewbeaton/hugo-drone image and execute the hugo command for production to build your Hugo site. I like to enable verbose and debug output to help with problem-solving, and I also output the current version of Hugo with each build.

Step 5: Building and Deploying with Drone

Now that everything is set up, you can build and deploy your Hugo site with Drone.

Commit and push the changes you made to your .drone.yml file. The Drone pipeline will automatically trigger, building your Hugo site.

Take a look at some of my other posts for examples on how to deploy to a web server or Cloudflare Pages.

Summary

The andrewbeaton/hugo-drone Docker image simplifies the process of building Hugo sites by providing a preconfigured environment. By following the steps outlined in this blog post, you can use this image to automate your Hugo builds, saving time and effort in the development and deployment process.

In this tutorial, I will walk you through the process of publishing a Docker image to GitHub’s Container Registry using GitHub Actions. By using GitHub Actions, you can automate the build and publish process, making it easier to distribute your Docker images.

Prerequisites

Before getting started, make sure you have the following:

1. A GitHub account.
2. A Dockerfile that describes your application’s dependencies and build instructions.
3. A GitHub repository where you want to publish your Docker image.

Step 1: Set up GitHub Actions workflow

GitHub Actions allow you to automate tasks by creating workflows.

To publish a Docker image, we’ll create a workflow file named publish.yml.

Create a new directory called .github/workflows in the root of your repository, if it doesn’t already exist.

Inside this directory, create a new file named publish.yml and add the following content:

name: Publish Docker Image

on:
  push:
    branches:
      - main

jobs:
  build-and-publish:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Login to GitHub Container Registry
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v2
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:${{ github.sha }}

This workflow will trigger whenever you push changes to the main branch. It checks out the code, logs in to GitHub’s Container Registry using your GitHub credentials, and builds and pushes the Docker image to the registry.

Step 2: Configure the Dockerfile

In your repository, create a file named Dockerfile and add the necessary instructions to build your Docker image. Here’s an example Dockerfile for a Node.js application:

FROM node:14

WORKDIR /app

COPY package.json package-lock.json ./

RUN npm ci --only=production

COPY app.js .

CMD ["node", "app.js"]

Make sure to modify the Dockerfile to suit your application’s requirements.

Step 3: Push changes to your repository

Commit and push the Dockerfile, publish.yml, and any other files you may have modified to your repository.

Step 4: Monitor the workflow execution

After pushing the changes, navigate to the “Actions” tab in your GitHub repository. You should see the workflow you created (“Publish Docker Image”) listed there. Click on it to monitor the execution.

Step 5: Verify the Docker image in GitHub Container Registry

Once the workflow execution is complete, go to the “Packages” tab in your GitHub repository. You should see your Docker image listed there. Click on it to view the details.

Summary

You have successfully published a Docker image to GitHub’s Container Registry using GitHub Actions. By automating this process, you can easily distribute your Docker images and ensure consistent deployment across different environments. GitHub Actions provides a powerful platform for automating various tasks in your development workflow, saving you time and effort.

Docker has become an essential tool in modern software development, enabling easy and efficient containerisation of applications. GitHub’s Container Registry provides a convenient way to store and manage Docker images within the GitHub ecosystem.

In this tutorial, we will walk through the process of creating, editing, and publishing a Docker image to GitHub’s Container Registry.

Prerequisites

Before we begin, ensure that you have the following:

1. A GitHub account
2. Docker installed on your local machine
3. Basic familiarity with Docker commands

Step 1: Create a Dockerfile

The first step is to create a Dockerfile, which defines the instructions to build your Docker image. Open a text editor and create a new file called Dockerfile. Here’s a basic example:

# Use a base image
FROM ubuntu:latest

# Set the working directory
WORKDIR /app

# Copy files to the container
COPY . /app

# Install dependencies
RUN apt-get update && apt-get install -y <your-package-name>

# Specify the command to run when the container starts
CMD ["<your-command>"]

Customise the FROM line with the base image you want to use and replace <your-package-name> with the required packages for your application. Also, update <your-command> with the command to start your application.

Step 2: Build the Docker Image

Once you have the Dockerfile ready, you can build the Docker image.

Open a terminal or command prompt and navigate to the directory containing the Dockerfile.

Run the following command:

docker build -t <image-name> .

Replace <image-name> with the desired name for your Docker image.

The . at the end specifies the build context, which includes the files needed for building the image.

Wait for the build process to complete.

Docker will execute the instructions in the Dockerfile and generate the image.

Step 3: Tag the Docker Image

To publish the Docker image to GitHub’s Container Registry, you need to tag it accordingly.

Run the following command:

docker tag <image-name> ghcr.io/<username>/<repository>:<tag>

Replace <username> with your GitHub username, <repository> with the name of the repository you want to push the image to, and <tag> with the desired tag (e.g., version number or latest).

Step 4: Log in to GitHub Container Registry

Before you can publish the image, you need to authenticate with GitHub’s Container Registry.

Run the following command:

docker login ghcr.io -u <username>

Replace <username> with your GitHub username. You will be prompted to enter your GitHub password or a personal access token.

Step 5: Publish the Docker Image

Now that you’re logged in, you can publish the Docker image to GitHub’s Container Registry.

Run the following command:

docker push ghcr.io/<username>/<repository>:<tag>

Replace <username>, <repository>, and <tag> with the values you used in Step 3.

Wait for the push process to complete. Once finished, your Docker image will be available in GitHub’s Container Registry, associated with your specified repository.

Step 6: Update and Re-Publish

If you make changes to your Docker image or need to update it with a new version, follow the steps again from Step 2 onwards.

Remember to tag the image with a new version number or an appropriate tag, and push it to GitHub’s Container Registry.

Markdown is a lightweight markup language that allows you to write formatted text using a plain-text syntax.

It’s widely used for writing documentation, blog posts, and even creating web pages.

In this cheat sheet, I’ll cover the most commonly used Markdown syntax and their corresponding formatting options.

Headings

You can create headings by using one to six hash characters (#) at the beginning of the line. The number of hashes represents the heading level.

# Heading 1
## Heading 2
### Heading 3
#### Heading 4
##### Heading 5
###### Heading 6

Emphasis

You can emphasise text using the following options:

• Bold: Surround the text with double asterisks (**) or double underscores (__).
• Italic: Surround the text with single asterisks (*) or single underscores (_).
• Bold and Italic: Combine both using triple asterisks (***) or triple underscores (___).

**Bold**

__Bold__

*Italic*

_Italic_

***Bold and Italic***

___Bold and Italic___

Lists

Markdown supports both ordered and unordered lists.

• Unordered List: Begin each item with a hyphen (-), plus sign (+), or asterisk (*).
• Ordered List: Begin each item with a number followed by a period (1., 2., etc.).

- Item 1
- Item 2
- Item 3

1. Item 1
2. Item 2
3. Item 3

Links

You can create links in Markdown using the following syntax:

• Inline Links: [Link Text](URL)
• Reference Links: [Link Text][Reference ID] and later [Reference ID]: URL

[Google](https://www.google.co.uk)

[Andrew Beaton][1]
[1]: https://andrewbeaton.net

Images

To include images in your Markdown document, use the following format:

![Alt Text](URL)

Code Blocks

You can display code blocks or inline code using backticks (`):

• Inline Code: Surround the code with single backticks.

• Code Block: Surround the code with triple backticks, optionally specifying the language for syntax highlighting.

console.log("Hello, Markdown!");

def greet():
    print("Hello, Markdown!")

Blockquotes

Blockquotes are used to display quoted text. You can create a blockquote by using a greater than symbol (>).

> This is a blockquote.

Horizontal Rule

To create a horizontal rule, use three or more hyphens (---), asterisks (***), or underscores (___).

---

Tables

Tables can be created using hyphens (-) and pipes (|) to define the columns and rows.

| Column 1 | Column 2 |
| -------- | -------- |
| Row 1    | Row 1    |
| Row 2    | Row 2    |

Escaping Characters

To display characters that have special meaning in Markdown, you can use a backslash (\) before the character to escape it.

\*This is not italic\*

Task Lists

You can create task lists using square brackets ([ ] for incomplete tasks and [x] for completed tasks).

- [ ] Task 1
- [x] Task 2
- [ ] Task 3

Strikethrough

To strike through text, use two tilde characters (~~).

~~This text is strikethrough.~~ 

Footnotes

Markdown supports footnotes, allowing you to add additional information or references at the bottom of the page.

Here is some text with a footnote[^1].

[^1]: This is the footnote content.

Superscript and Subscript

To create superscript and subscript text, use the caret (^) for superscript and tilde (~) for subscript.

This is a superscript: X^2^
This is a subscript: H~2~O

Abbreviations

Markdown allows you to define abbreviations, which can be useful for providing explanations or definitions.

The HTML stands for Hypertext Markup Language. [^HTML]

[^HTML]: Hypertext Markup Language

Raw HTML

Markdown supports the use of raw HTML code for more advanced formatting options. You can embed HTML elements directly within your Markdown document.

This is a <span style="color: red;">red</span> text.

Inline Math Equations

If you need to include mathematical equations, you can use LaTeX syntax within Markdown to render them.

The quadratic equation is \(ax^2 + bx + c = 0\).

Definition Lists

Markdown also supports definition lists for glossaries or terms with corresponding explanations.

Term 1
:   This is the definition of Term 1.

Term 2
:   This is the definition of Term 2.

Inline HTML

Markdown allows you to directly insert HTML code inline within your Markdown document. This can be useful for more complex formatting or embedding multimedia.

This is an <kbd>inline HTML</kbd> example.

Definition of Acronyms

Similar to abbreviations, Markdown supports the definition of acronyms using the same syntax.

The HTTP stands for Hypertext Transfer Protocol. [^HTTP]

[^HTTP]: Hypertext Transfer Protocol

Emoji

Markdown supports the use of emojis to add visual elements to your text. You can include emojis using emoji codes or Unicode characters. 😃

I am feeling 😃 today!

Automatic URL Linking

By default, Markdown automatically converts URLs into clickable links. You don’t need to use any specific syntax.

Visit my website at https://andrewbeaton.net

Escape Characters

If you want to display characters that have a special meaning in Markdown, you can escape them using a backslash (\).

\*This is not a bullet point\*

Summary

This cheat sheet covers the most commonly used Markdown syntax.

Markdown provides a simple and efficient way to format text without getting in the way of your writing.

These days, securing your systems and data is of great importance.

One powerful security measure is Multi-Factor Authentication (MFA), which adds an extra layer of protection by requiring users to provide additional credentials beyond just a password.

In this post, I will guide you through the process of setting up MFA on Ubuntu 22.04, enhancing the security of your system.

Prerequisites

Before we begin, make sure you have the following:

• A user account with sudo privileges.
• Ubuntu 22.04 installed (Not tested on other versions).
• An MFA authenticator app, such as Google Authenticator or Authy.

Step 1: Install the Required Packages

The first step is to install the necessary packages that will enable MFA on your Ubuntu system.

Open a terminal and run the following commands:

sudo apt update
sudo apt install libpam-google-authenticator -y

These commands will update your package lists and install the libpam-google-authenticator package, which will be used to generate MFA codes.

Step 2: Configure MFA for a User

Once the package is installed, you can configure MFA for a specific user account.

In the terminal, execute the following command:

google-authenticator

This command will initiate the setup process and present you with a series of questions.

You will be prompted to scan a QR code with an MFA authenticator app, such as Google Authenticator or Authy. Alternatively, you can enter the provided key manually into your authenticator app.

You will be asked if you want to update the .google_authenticator file. Press y and hit Enter to proceed.

You will be asked a series of questions. It is recommended to answer ‘y’ for all the questions to enable the maximum level of security. These questions include options such as disallowing multiple uses of the same authentication token and enabling rate limiting.

Once you have completed the setup, you will be provided with backup codes.

It is crucial to store these backup codes in a secure location, as they can be used to access your account if you lose access to your MFA device.

Step 3: Configure SSH to Use MFA

To enable MFA for SSH logins, you need to configure the SSH daemon to utilise MFA.

Open the SSH configuration file by running the following command:

sudo nano /etc/pam.d/sshd

In the editor, add the following line at the top of the file:

auth required pam_google_authenticator.so

Save the changes and exit the editor by pressing Ctrl + X, followed by Y, and then hitting Enter.

Step 4: Restart SSH Service

To apply the changes made to the SSH configuration, you need to restart the SSH service.

Run the following command to restart SSH:

sudo systemctl restart sshd

Step 5: Test MFA

Now that MFA is set up, it’s time to test if it’s working as expected.

Open a new terminal window and attempt to SSH into your Ubuntu system using the user account you configured for MFA.

You should be prompted for your MFA verification code after entering your password.

Summary

You have successfully set up Multi-Factor Authentication (MFA) on your Ubuntu 22.04 system.

By implementing MFA, you have significantly enhanced the security of your system and reduced the risk of unauthorised access.

Remember to keep your backup codes safe in case you need them.

Ackee is a self-hosted, open-source, privacy focused, analytics platform that provides useful insights into your website’s traffic.

By running Ackee in a Docker container, you can easily deploy and manage it on your own server.

In this guide, I’ll talk you through the process of creating an Ackee Docker container and setting it up using Docker Compose.

Prerequisites

Before you start, ensure you have the following:

• Docker installed on your server.

• Docker Compose installed on your server.

• Basic knowledge of working with Docker and Docker Compose.

Create a Docker Compose File

Open your text editor and create a new file named docker-compose.yml.

In this file, we define the configuration for the Ackee Docker container.

Define the Docker Compose Configuration

Copy and paste the following configuration into your docker-compose.yml file:

version: '3'
services:
  ackee:
    image: electerious/ackee
    container_name: ackee
    restart: always
    ports:
      - "3000:3000"
    environment:
      - WAIT_HOSTS=mongodb:27017
      - DATABASE_URI=mongodb://mongo:27017/ackee
    depends_on:
      - mongo
  mongo:
    image: mongo
    container_name: mongo
    restart: always
    ports:
      - '27017:27017'
    volumes:
      - ackee-mongo:/data/db
volumes:
  ackee-mongo:

This configuration defines two services: ackee and mongo.

The ackee service uses the electerious/ackee Docker image, exposes port 3000, sets the DATABASE_URI environment variable to connect to the MongoDB instance, and depends on the mongo service.

The mongo service uses the mongo Docker image and mounts a volume to persist MongoDB data.

Save the Docker Compose File

Save the docker-compose.yml file in your desired directory on your server. Make sure you remember the location as we’ll use it in the next step.

Start the Ackee Docker Container

Open a terminal or command prompt and navigate to the directory where you saved the docker-compose.yml file.

Run the following command to start the Ackee Docker container:

docker-compose up -d

Docker Compose will download the necessary Docker images and start the Ackee and MongoDB containers in detached mode.

Access Ackee in your Web Browser

Open your web browser and enter the following URL:

http://localhost:3000

You should now see the Ackee login page.

Create a new user account and log in to the Ackee dashboard.

You have now successfully created an Ackee Docker container and set it up using Docker Compose. You can now start analyzing your website’s traffic using Ackee’s powerful analytics features.

Additional Configuration Options

If you want to use a different port for Ackee, you can modify the ports section in the docker-compose.yml file:

ports:
    - "3000:3000"

To allow your domains to connect to Ackee, you can set the ACKEE_ALLOW_ORIGIN environment variable and list your domains:

ACKEE_ALLOW_ORIGIN=https://domain1.com,https://domain2.com

You can specify your username and password in the docker-compose.yml file with the environment variables:

- ACKEE_USERNAME=username
- ACKEE_PASSWORD=password 

Remember to regularly update the docker-compose.yml file to use the latest version of Ackee and MongoDB images to benefit from the latest features and security patches.

Summary

With Docker Compose, managing your Ackee deployment becomes seamless, allowing you to focus on gaining valuable insights from your website’s analytics data.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Ackee
Docker Docker Compose

Due to some unexpected downtime with my current web host, and a bit of spare time on my hands, I thought I would give a go at configuring Drone to deploy to Cloudflare Pages.

A very basic description of Cloudflare Pages, is that it’s a platform that makes it easy to create and host websites whilst Cloudflare takes care of the more technical side of website hosting. For a more technical overview, take a look at the official documentation.

For my use case, as I use Hugo to generate all my static website files, I can just use Cloudflare Pages to host the content. With my domain name already proxying through Cloudflare, everything is now all handled in one place, and so far, it all just works.

So let’s cover off what’s needed to get Drone to deploy your Hugo (or static files) to Cloudflare Pages.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• A working Hugo website:
  • Set up a Hugo website.
• A Git repository:
  • Host your Hugo website’s code in a Gitea / Git repository.
• A working Drone instance:
  • Your Drone instance should be working correctly with your Gitea repository.
• A Cloudflare account:
  • Your Cloudflare account is running, and you have configured both a new Cloudflare Page and have a Cloudflare Workers API set up.

A Drone Build Step for Cloudflare Pages

This guide follows on from my previous post where I walk through setting up a full drone pipeline with Test, Staging and Production builds and deployments. To catch up have a look at Creating a Full Drone Pipeline with Gitea and Drone

The following is a step that will build static content located in /drone/src//. Deploy to a Cloudflare Page defined by , and a Drone secret called <CLOUDFLARE_API_TOKEN> containing a Cloudflare API token.

- name: Build Node.js
    image: node:latest
    commands: 
      - npm install npm@latest -g 
      - mkdir -p dist
      - cp -R /drone/src/<your static files location>/* dist/ 

  - name: Deploy to Cloudflare Pages
    image: node:latest
    environment:
      CLOUDFLARE_API_TOKEN:
        from_secret: CLOUDFLARE_API_TOKEN
    commands: 
      - npm install wrangler --save-dev  
      - cd /drone/src/dist/
      - npx wrangler pages deploy /drone/src/dist --project-name "<project>" --env production --branch main --commit-dirty=true

There are a number of Docker images out there using Wrangler to deploy to Cloudflare. Unfortunately they all seem to use the previous version of the Cloudflare API which will deprecated shortly. So I went down the route of building Wrangler and NodeJS directly.

Do get in touch if you find a more recent Docker image for me to try.

A Drone Pipeline for Cloudflare Pages

This is a direct copy of my current production build pipeline. This has added debugging information that I find useful whilst making changes.

---
kind: pipeline
type: docker
name: "Production Environment"

trigger:
  branch: 
    - main 
  event:
    include:
      - push

steps:   
  - name: Clone Git Submodules
    image: alpine/git 
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment production --verbose --debug 
      - ls -al /drone/src/hugo/public

  - name: Build Node.js
    image: node:latest
    commands:
      - ls -la /drone/src/
      - npm install npm@latest -g
      - pwd
      - mkdir -p dist
      - cp -R /drone/src/hugo/public/* dist/
      - ls -la dist/

  - name: Deploy to Cloudflare Pages
    image: node:latest
    environment:
      CLOUDFLARE_API_TOKEN:
        from_secret: CLOUDFLARE_API_TOKEN
    commands:
      - ls -la /drone/src/
      - npm install wrangler --save-dev 
      - npx wrangler --version
      - cd /drone/src/dist/
      - npx wrangler pages deploy /drone/src/dist --project-name "<project-name>" --env production --branch main --commit-message "Drone Production Build" --commit-dirty=true

Summary

Once deployed, a new Deployment will be available for you in your Cloudflare Pages area that can be accessed either by the temporary preview deployment domain or your preview alias project domain.

Once happy you can now set up a custom domain to point to the new Page.

Although a few extra steps than an existing Docker Cloudflare setup, this method does allow you to clearly see what’s going on and debug any issues should they happen.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Cloudflare Workers Gitea Drone Hugo

In my previous posts, I’ve covered how to set up Drone, Gitea and deploy a build to an FTP server. In this post, I’ll be covering how to configure a full pipeline to include:

• A continuous testing build on each commit to the Develop branch.
• An automated build to a staging environment on commit to the Main branch.
• A manual deployment to a production environment using the Promote function in Drone.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• A working Hugo website:
  • Set up a Hugo website locally.
• A Git repository:
  • Host your Hugo website’s code in a Gitea repository.
• A working Drone instance:
  • Your Drone instance should be working correctly with your Gitea repository.
• An FTP server
  • An FTP server configured with username and password, a valid user home directory and web content loaded from that location.

What is a Drone Pipeline?

In Drone, a pipeline refers to a sequence of steps and actions that are executed in a predefined order to build, test, and deploy software. It provides a structured and automated workflow for managing the different stages of the development process.

A pipeline in Drone is typically defined using a configuration file named ‘.drone.yml’. This file specifies the steps to be executed, the order in which they should run, and any required configurations or dependencies.

Here are the key components and concepts associated with a pipeline in Drone:

• Stages:
  A pipeline is divided into stages, which represent different phases of the software development lifecycle. Common stages include building, testing, and deploying. Each stage contains one or more steps that define the actions to be performed.

• Steps:
  Steps are the individual units of work within a stage. They represent specific actions to be executed, such as running a command, running tests, or deploying the application. Steps can be executed sequentially or in parallel, depending on the requirements.

• Dependencies:
  A step in a pipeline may have dependencies on previous steps. This allows for the establishment of a logical flow, where certain steps must be completed successfully before proceeding to the next ones. Dependencies ensure that the pipeline runs in a consistent and controlled manner.

• Conditions:
  Conditions are used to control the execution of steps based on specific criteria. For example, a step may only run if a certain condition is met, such as the branch name, the outcome of a previous step, or the presence of a specific environment variable. Conditions provide flexibility and allow for conditional execution based on the project’s needs.

• Artifacts:
  Artifacts are files or directories generated during the pipeline execution that can be passed between steps or stored for later use. They allow for sharing data, test reports, build artifacts, or any other relevant files between different stages of the pipeline.

• Triggers:
  Triggers determine when the pipeline should run. They can be defined to automatically start the pipeline on specific events, such as code pushes, pull requests, or scheduled intervals. Triggers ensure that the pipeline is executed whenever a relevant change occurs, maintaining an up-to-date and automated development process.

Development Build

In my current setup, every commit to the Develop branch is picked up by Drone and creates a build. This build pulls the develop branch from the Gitea repository, installs the Hugo modules and builds the Hugo website in development mode.

I have also set this to fail on any warnings, so that I can quickly see if there are any problems with my code.

This step is where I would run any tests on the output code and fail the build should any fail. More to come on that in future posts.

The specific steps for this in the drone.yaml file are:

---
kind: pipeline
type: docker
name: "Test Environment"

trigger:
  branch: 
    - develop 
  event:
    include:
      - push

steps:   
  - name: Clone Git Submodules
    image: alpine/git 
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      # Disable panicOnWarning due to bug in Hugo.
      - hugo --environment development --verbose --debug # --panicOnWarning
      - ls -al /drone/src/hugo/public

As you can see, every push to the ‘develop’ branch will trigger the following steps. I have this configured to also show debug and more verbose information to help with investigating any problems. You’ll see I also specify the development environment in Hugo, this is to prevent items such as Google Analytics from running in a test setup.

Staging Build

My staging build is run when a commit is made to the main branch. A nice approach would be to lock down the main branch so that no commits can be made directly to it. Any merges from the develop branch must come via a pull request. A tad overkill for a home setup, but it’s good practice.

This build will do the same as the Test build, but also includes a step to deploy to my staging web server.

---
kind: pipeline
type: docker
name: "Staging Environment"

trigger:
  branch:
    - main
  event:
    include: 
      - push

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment develop --verbose
      - ls -al /drone/src/hugo/public

  - name: Deploy to Staging FTP
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
          from_secret: staging_ftp_username
        FTP_PASSWORD:
          from_secret: staging_ftp_password 
        PLUGIN_SECURE: true
        PLUGIN_VERIFY: true
        PLUGIN_HOSTNAME:
          from_secret: staging_ftp_hostname
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: 
          from_secret: staging_ftp_directory
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

You can see that I specify the environment for Hugo, as development. And this time, take advantage of Drone secrets for the Staging server details and credentials.

Production Build

Now the production build is slightly different, in that it can only be run through Drone by promoting an existing successful Staging build.

---
kind: pipeline
type: docker
name: "Production Environment"

trigger:
  target: 
    - production

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment production --verbose
      - ls -al /drone/src/hugo/public

  - name: Deploy to Production FTP
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
          from_secret: production_ftp_username
        FTP_PASSWORD:
          from_secret: production_ftp_password 
        PLUGIN_SECURE: true
        PLUGIN_VERIFY: true
        PLUGIN_HOSTNAME:
          from_secret: production_ftp_hostname
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: 
          from_secret: production_ftp_directory
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

Here you’ll see that we change the environment for Hugo to be production and use Drone secrets again to specify the Production details and credentials.

Complete Drone Configuration

Putting all of these steps together, the complete config.yml file looks like this:

---
kind: pipeline
type: docker
name: "Test Environment"

trigger:
  branch: 
    - develop 
  event:
    include:
      - push

steps:   
  - name: Clone Git Submodules
    image: alpine/git 
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      # Disable panicOnWarning due to bug in Hugo.
      - hugo --environment development --verbose --debug # --panicOnWarning
      - ls -al /drone/src/hugo/public

---
kind: pipeline
type: docker
name: "Staging Environment"

trigger:
  branch:
    - main
  event:
    include: 
      - push

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment development --verbose
      - ls -al /drone/src/hugo/public

  - name: Deploy to Staging FTP
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
          from_secret: staging_ftp_username
        FTP_PASSWORD:
          from_secret: staging_ftp_password 
        PLUGIN_SECURE: true
        PLUGIN_VERIFY: true
        PLUGIN_HOSTNAME:
          from_secret: staging_ftp_hostname
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: 
          from_secret: staging_ftp_directory
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

---
kind: pipeline
type: docker
name: "Production Environment"

trigger:
  target: 
    - production

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment production --verbose
      - ls -al /drone/src/hugo/public

  - name: Deploy to Production FTP
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
          from_secret: production_ftp_username
        FTP_PASSWORD:
          from_secret: production_ftp_password 
        PLUGIN_SECURE: true
        PLUGIN_VERIFY: true
        PLUGIN_HOSTNAME:
          from_secret: production_ftp_hostname
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: 
          from_secret: production_ftp_directory
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

Summary

With the above setup, you can see how easily a full work flow can be configured in Drone that will enable automatic and continuous builds and deployments. Hopefully saving you some time in the future and catching any problems well before they reach the production environment.

I’ll continue documenting my journey with Gitea, Drone and Hugo and share the interesting things I find along the way.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Gitea Drone Hugo

This is the setup that I’m using for both my staging website and my production one (This one!).

Hugo does come with a built-in server for viewing your site locally but having a staging site gives me more confidence that everything will work correctly when deployed to my main website, especially as the whole process is automated.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• A working Hugo website:
  • Set up a Hugo website locally.
• A Git repository:
  • Host your Hugo website’s code in a Git repository.
• An FTP server
  • An FTP server configured with username and password, a valid user home directory and web content loaded from that location.

Step 1: Configure the Drone.io Pipeline

1. In your websites Git repository, create a .drone.yml file in the root directory.
2. Add the following code to the .drone.yml file:

kind: pipeline
name: your-pipeline-name

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote
      
  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --verbose 
      - ls -al /drone/src/hugo/public 
      
  - name: Deploy to FTP server
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
            from_secret: ftp_username
        FTP_PASSWORD:
            from_secret: ftp_password 
        PLUGIN_SECURE: false
        PLUGIN_VERIFY: false
        PLUGIN_HOSTNAME: ftp://host:21
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: /home/ftp_username
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

Replace your-pipeline-name with a suitable name for your pipeline.

3. Adjust the PLUGIN_HOSTNAME and PLUGIN_DEST_DIR fields to match your remote server details and deployment directory.

4. Add secret for your remote server’s username and password by going to your Drone.io repository settings and adding secrets with the keys ftp_username, ftp_password and the corresponding values.

Step 2: Trigger the Pipeline

1. Push your updated .drone.yml file to your Git repository.
2. This will trigger the Drone.io pipeline to run.
3. Monitor the build process in the Drone.io interface to ensure everything is working correctly.
4. Once the pipeline completes successfully, your Hugo website will be deployed to the specified remote server.

You have successfully set up Drone with an FTP server. Now, whenever you push changes to your Git repository, Drone.io will automatically build your Hugo website and deploy it to your remote FTP server.

I’ll continue documenting my journey with Gitea, Drone and Hugo and share the interesting things I find along the way.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Gitea Drone Hugo

In this guide, I’ll walk you through the process of setting up Hugo with a local Drone.io instance and a local Gitea server, allowing you to automate your website deployment workflow in a self-hosted environment.

I used this setup initially, before changing the Drone deployment to upload through FTP to my local staging web server. If you’re interested in this setup, you can find the details in the guide Deploy to an FTP server with Drone.

Note

The instructions below cover the setup and running of the Docker instances locally. If you are setting this up in your home lab, then just change the references from local to the details of your servers.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• Docker installed:
  • Make sure you have Docker installed on your local machine or remote server.
• Basic knowledge of Docker:
  • Familiarity with Docker and Docker Compose will be helpful.
• A working Hugo website:
  • Set up a Hugo website locally.

Step 1: Set up Gitea

1. Create a new directory on your machine for the Gitea Docker configuration.
2. Create a docker-compose.yml file within that directory and add the following content:

version: '3'
services:
  gitea:
    image: gitea/gitea:latest
    ports:
      - "3000:3000"
      - "2222:22"
    volumes:
      - ./gitea-data:/data
    restart: always

3. Save the file and navigate to the Gitea Docker configuration directory in your terminal.
4. Run the command docker-compose up -d to start the Gitea container.

Gitea should now be accessible at http://localhost:3000. Follow the on-screen instructions to set up an admin account and create a new repository for your Hugo website.

Step 2: Set up Drone.io

1. Create a new directory on your machine for the Drone.io Docker configuration.
2. Create a docker-compose.yml file within that directory and add the following content:

version: '3'
services:
  drone-server:
    image: drone/drone:latest
    ports:
      - "8080:80"
    volumes:
      - ./drone-data:/data
    restart: always
    environment:
      - DRONE_GITEA_SERVER=http://gitea:3000
      - DRONE_GITEA_CLIENT_ID=your-gitea-client-id
      - DRONE_GITEA_CLIENT_SECRET=your-gitea-client-secret

  drone-runner:
    image: drone/drone-runner-docker:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    restart: always

3. Save the file and navigate to the Drone.io Docker configuration directory in your terminal.

4. Replace your-gitea-client-id and your-gitea-client-secret with the appropriate values. These can be obtained by registering a new OAuth application within Gitea’s settings.

5. Run the command docker-compose up -d to start the Drone.io containers.

Drone.io should now be accessible at http://localhost:8080. Sign in with your Gitea credentials and authorise Drone.io to access your Gitea repositories.

Step 3: Configure the Drone.io Pipeline

1. Within your Hugo website’s repository, create a .drone.yml file in the root directory.
2. Add the following code to the .drone.yml file:

kind: pipeline
name: your-pipeline-name

steps: 
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote
      
  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --verbose 
      - ls -al /drone/src/hugo/public

  - name: Deploy
    image: appleboy

  - name: deploy
    image: appleboy/drone-scp
    settings:
      host: your-remote-host
      username: your-remote-username
      password: your-remote-password
      source:
        - /hugo/public/
      target: /path/to/your/remote/directory

Replace your-pipeline-name with a suitable name for your pipeline.

3. Adjust the host, username, password, and target fields to match your remote server details and deployment directory.

Step 4: Trigger the Pipeline

1. Push your updated .drone.yml file to your Gitea repository.
2. This will trigger the Drone.io pipeline to run.
3. Monitor the build process in the Drone.io interface to ensure everything is working correctly.
4. Once the pipeline completes successfully, your Hugo website will be deployed to the specified remote server.

You have successfully set up Hugo with a local Drone.io instance and a local Gitea server. Now, whenever you push changes to your Gitea repository, Drone.io will automatically build your Hugo website and deploy it to your remote server.

I’ll continue documenting my journey with Gitea, Drone and Hugo and share the interesting things I find along the way.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Gitea Drone Hugo

In this guide, I’ll walk you through the process of setting up Hugo with a Docker Drone.io container and GitHub, allowing you to streamline your website deployment workflow.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• Docker installed:
  • Ensure you have Docker installed on your local machine.
• Basic knowledge of Docker:
  • Familiarity with Docker and Docker Compose will be helpful.
• A working Hugo website:
  • Set up a Hugo website locally.
• A GitHub repository:
  • Host your Hugo website’s code in a GitHub repository.

Step 1: Set Up a Docker Drone.io Container

1. Create a new directory on your machine for the Docker Drone.io container configuration.
2. Create a docker-compose.yml file within that directory and add the following content:

version: '3'
services:
  drone-server:
    image: drone/drone:latest
    ports:
      - "8080:80"
    volumes:
      - ./drone-data:/data
    restart: always
    environment:
      - DRONE_GITHUB_CLIENT_ID=your-github-client-id
      - DRONE_GITHUB_CLIENT_SECRET=your-github-client-secret

  drone-runner:
    image: drone/drone-runner-docker:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    restart: always

3. Save the file and navigate to the Docker Drone.io container configuration directory in your terminal.

4. Replace your-github-client-id and your-github-client-secret with the appropriate values. These can be obtained by registering a new OAuth application within GitHub’s settings.

5. Run the command docker-compose up -d to start the Docker Drone.io container.

Drone.io should now be accessible at http://localhost:8080.

Step 2: Connect Drone.io to GitHub

1. Open Drone.io in your web browser at http://localhost:8080.
2. Sign in with your GitHub credentials.
3. Authorise Drone.io to access your GitHub repositories.

Step 3: Configure the Drone.io Pipeline

1. Within your Hugo website’s GitHub repository, create a .drone.yml file in the root directory.
2. Add the following code to the .drone.yml file:

kind: pipeline
name: your-pipeline-name

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote
      
  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --verbose 
      - ls -al /drone/src/hugo/public 

  - name: Deploy
    image: appleboy/drone-scp
    settings:
      host: your-remote-host
      username: your-remote-username
      password:
        from_secret: your-remote-password-secret
      source: 
        - /hugo/public/
      target: /path/to/your/remote/directory

Replace your-pipeline-name with a suitable name for your pipeline.

3. Adjust the host, username, password, and target fields to match your remote server details and deployment directory.

4. Add a secret for your remote server’s password by going to your Drone.io repository settings and adding a secret with the key your-remote-password-secret and the corresponding value.

Step 4: Trigger the Pipeline

1. Push your updated .drone.yml file to your GitHub repository.
2. This will trigger the Drone.io pipeline to run.
3. Monitor the build process in the Drone.io interface to ensure everything is working correctly.
4. Once the pipeline completes successfully, your Hugo website will be deployed to the specified remote server.

You have successfully set up Hugo with a Docker Drone.io container and GitHub. Now, whenever you push changes to your GitHub repository, Drone.io will automatically build your Hugo website and deploy it to your remote server.

I’ll continue documenting my journey with Gitea, Drone and Hugo and share the interesting things I find along the way.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Gitea Drone Hugo

From my previous posts, you can see that I use Ansible a fair bit for my personal projects, but at work, being a C# developer and working for an organisation that is predominantly Microsoft based, we use Terraform by HashiCorp for infrastructure automation.

I’ve been keeping a close eye on a project by Telmate on Github. They have been working on the Terraform Proxmox Provider and a few days ago a commit was made to allow the creation of Linux Containers (LXC) in Proxmox as opposed to just the creation of Virtual Machines (VMs), so I was keen to give it a go.

Requirements

I’m using macOS Catalina as my development machine, so the instructions will be based on this platform, but the tools will be the same and installation may differ.

Go

Download and install Go from Go’s website. Or by a direct link to MacOS Go 1.13.3

Terraform Provider and Provisioner

Using Go, get the latest Terraform provider and provisioner for Proxmox.

These instructions differ slightly from those on the Terraform Proxmox Provider Github page, but they are what worked for me.

go get github.com/Telmate/terraform-provider-proxmox/cmd/terraform-provider-proxmox
go install github.com/Telmate/terraform-provider-proxmox/cmd/terraform-provider-proxmox

go get github.com/Telmate/terraform-provider-proxmox/cmd/terraform-provisioner-proxmox
go install github.com/Telmate/terraform-provider-proxmox/cmd/terraform-provisioner-proxmox

Copy them to the correct locations:

which terraform-provider-proxmox
~/go-workspace/bin/terraform-provider-proxmox
which terraform-provisioner-proxmox
~/go-workspace/bin/terraform-provisioner-proxmox 

cd ~/.terraform.d
mkdir plugins
cd plugins
cp ~/go-workspace/bin/terraform-provider-proxmox .
cp ~/go-workspace/bin/terraform-provisioner-proxmox .

Example of container creation

Using the example below, after updating your own values, a new container will be created, ready to be started.

I found it simple enough to create a new container using the Proxmox GUI and comparing the values with the resources in the example below and a little trial and error.

For a list of all the resources available that you can set, it’s worth having a read through of the resource_lxc.go code on Github.

provider "proxmox" {
    pm_tls_insecure = true
    pm_api_url = "https://proxmox.home.lan:8006/api2/json"
    pm_user = "terraform@pam"
    pm_password = "<secure password>"
}

resource "proxmox_lxc" "lxc-test" { 
    hostname = "lxc-test-host"
    cores = 1
    memory = "1024"
    swap = "2048"
    network {
        name = "eth0"
        bridge = "vmbr0"
        ip = "192.168.1.69/24"  
        firewall = true
    }
    ostemplate = "local:vztmpl/ubuntu-18.04-custom.tar.gz" 
    password = "<secure password>"
    pool = "terraform"
    rootfs = "local-lvm2:8" 
    storage = "local-lvm2"
    target_node = "proxmox"
    unprivileged = true
}

Run

terraform init
terraform plan
terraform apply

Homebrew Cask extends Homebrew. Bringing its simplicity and speed to the installation and management of GUI macOS applications such as Atom and Google Chrome.

To install an application or cask using Homebrew Cask you can run the following simple command:

brew cask install [application name]

An easy example that would install Spotify for example, is:

brew cask install spotify

To search for an application, do:

brew cask search [application name]

And finally, to remove an application:

brew cask uninstall [application name]

Homebrew provides a nice little web page for finding applications that are available to be installed and you can access this on the Homebrew website.

Sometimes you may find it useful to be able to install a different version of an application, if you want a beta release or to run a previous version. 1Password 6 or Google Chrome Beta are good examples here.

We do this by using the Homebrew tap command to connect in another repository. We will be using the homebrew-cask-versions repository from GitHub.

brew tap homebrew/cask-versions

And to install our specific version, we use this command:

brew cask install 1Password6

If you want to easily install command line tools such as cask, htop, wget, nmap, tree or virtually any other familiar unix command line tools, you can do so with a simple command. Homebrew downloads and builds the package for you.

If you spend a lot of time in the terminal environment then you should really see the benefit and value of Hombrew.

Before you can install Homebrew you need to make sure that you are running Mac OS X 10.10 or later and have the Command Line Tools for Xcode installed. This will allow you to build software from source. You can either install this directly from Apple or from the terminal by running this command:

sudo xcode-select --install

Once installed, which may take a few minutes, you can install Homebrew by running this command:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"  

To confirm the installation was successful and that you are ready to go, run this command:

brew doctor

If you are the type of person who likes to read manuals, give the following command a go:

brew help 

To show how simple it is to install something with Homebrew, you just need to use the following syntax:

brew install [package name] 

So to install wget, it’s as easy as:

brew install wget

You can search for packages with the following:

brew search [package name]

And to remove a package, it’s:

brew remove [package name]

Homebrew now defaults to sending anonymised behavioural analytics. If you do not want to participate in that for privacy purposes you can run the following command which will opt out of Homebrew analytics:

brew analytics off

Purchasing a subscription from Proxmox is certainly recommended if you’re planning to use it in anger or in a production environment as it will give you access to support, the enterprise repository and keep the developers supported.

But for a test environment, you can remove the message by simply editing one of the JavaScript files on the server.

This file does get overwritten when you update, so you will need to reapply when that happens.

Detailed Approach

cd /usr/share/javascript/proxmox-widget-tookit
cp proxmoxlib.js proxmoxlib.js.old
vi proxmoxlib.js

Search for Active until you find it in the following line:

if (data.status !== 'Active') {

And change it to:

if (false) {

Save the file and exit. Now restart the service to load the updated file:

systemctl restart pveproxy.service

One Liner Approach

sed -i.bak "s/data.status !== 'Active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

Even if you are feeling brave, I would recommend that you take a backup of proxmoxlib.js file before running the above command, just to be safe.