DEV Community: Dominik Zarsky

Automate your Laravel app deployments with Azure DevOps

Dominik Zarsky — Wed, 01 Mar 2023 18:54:25 +0000

Deploying Laravel applications can be a tedious and time-consuming process, but with the use of continuous integration and continuous deployment (CI/CD) pipelines, the process can be automated. Azure DevOps is a popular choice for creating such pipelines, as it offers a wide range of tools for building, testing and deploying code. In this article, we will explore how to configure a build pipeline and release pipeline, and automate the deployment of a Laravel application using Azure DevOps.

About Azure DevOps

Azure DevOps Services is a cloud-based CI/CD and project management tool developed by Microsoft. It also has an on-premises alternative called Azure DevOps Server.

Most of the features of this tool are free to use for companies and individual developers (up to certain limits), including private git repositories, Boards for project management, Test cases, Artifact repositories (for storing npm, NuGet or Python packages) and Azure Pipelines to support your CI/CD processes.

In this article, we are going to be looking at Azure Pipelines via Azure DevOps Services.

Setting up the repository and the Build pipeline

For this article, I have created a starter MVC application with Laravel Breeze and React which will be hosted on GitHub (this is not a prerequisite as Azure DevOps has excellent support for other platforms such as GitLab or BitBucket as well).

For the build, a free Azure DevOps account is required. The free tier limits are described on the Pricing page. To summarize - the free tier includes:

1800 minutes per month for builds and releases running on the Microsoft-hosted agents for private projects (self-hosted agents have no limits, public projects have no limits on the Microsoft-hosted agents as well)
Unlimited private git repositories (we will not be using these)
2GB artifact storage (should be plenty as Laravel build artifacts do not consume much space anyway)
Azure Boards for project management
One parallel job (build or release) running

The account can be created here. If you already have an Azure subscription, you can use your Azure account as well.

After the signup, create a project and connect your git repository. For this article, I will be using a public project which is publicly visible by default. This will make all the builds, artifacts and repositories in such projects also public. Use a private project if your pipelines are intended to be private.

To create a build pipeline, we first need to create a YAML file describing the build process. This file is usually called azure-pipelines.yaml and is stored in the root of the git repo. Other naming conventions (for example ci.yaml) and file locations can also be used. This file can be either created manually or via Azure DevOps. For me, configuring the pipeline via Azure DevOps is the preferred way as all the possible build tasks and their options are listed and can be used as helpers for building the pipeline. You can also use the Classic pipelines alternative which is a no-code solution to building your pipelines. I generally recommend having pipelines stored as code, thus I will not be covering Classic pipelines in this article.

The steps to create a new pipeline directly from Azure DevOps are as follows:

Go to your projects at https://dev.azure.com/your_organization
Select your project
In the left menu, go to Pipelines and select Pipelines from the submenu
Click Create Pipeline
Select the GitHub with YAML option
Select your repo (you might need to authenticate to GitHub and grant repo permissions)
In the Configure your pipeline section, select Starter pipeline

You should end up on the following screen:

From this screen, you can start writing the pipeline. Azure Pipelines are well documented by Microsoft, you can check out the documentation here.

For now, let's focus on the steps needed to build the pipeline for our Laravel application. The final build pipeline looks as follows:

trigger:
- master

pool:
  vmImage: ubuntu-latest

variables:
  phpVersion: 8.1

steps:
- script: |
    sudo update-alternatives --set php /usr/bin/php$(phpVersion)
    sudo update-alternatives --set phar /usr/bin/phar$(phpVersion)
    sudo update-alternatives --set phpdbg /usr/bin/phpdbg$(phpVersion)
    sudo update-alternatives --set php-cgi /usr/bin/php-cgi$(phpVersion)
    sudo update-alternatives --set phar.phar /usr/bin/phar.phar$(phpVersion)
  displayName: 'Use PHP version $(phpVersion)'

- script: composer install --no-interaction --prefer-dist
  displayName: 'composer install'

- task: NodeTool@0
  inputs:
    versionSpec: '18.x'
  displayName: 'Install NodeJS'

- task: Npm@1
  inputs:
    command: 'install'
    workingDir: '$(Build.SourcesDirectory)'
  displayName: 'npm install'

- task: Npm@1
  inputs:
    command: 'custom'
    workingDir: '$(Build.SourcesDirectory)'
    customCommand: 'run build'
  displayName: 'npm build'

- task: CopyFiles@2
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: |
      **/**
      !**/node_modules/**
      !**/.git/**
      !**/storage/**
    TargetFolder: '$(Build.ArtifactStagingDirectory)'
    CleanTargetFolder: true
    OverWrite: true
  displayName: 'Copy files to publish directory'

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'
    StoreAsTar: true

Let's dissect the pipeline a little:

The trigger determines a Continual Integration (CI) trigger on a branch of your project. If the branch is defined in the trigger array, the build will run every time code is pushed into the branch. It will also run build validation on pull requests
The pool determines an agent pool which will be used for the build. In this case, ubuntu-latest is used. You can also use Windows and MacOS agents. These agents are hosted by Microsoft and their use is counted towards the free build minutes included in the Azure DevOps Free Tier. You can also use self-hosted agents (these will be covered in the next section of this article)
As this is not a multi-stage build, steps, which describe the tasks the pipeline has to run, are defined directly in the base of the YAML file
The first couple of steps is to install dependencies - PHP, Composer and NodeJS. On Ubuntu agents, PHP and Composer are installed by default, we only have to select the version of PHP which we want to use. This is achieved by setting the version in the variables section and consequently using the update-alternatives command inside the first script task
We then run composer install to install dependencies. In this case, the application sits in the root of the git repo so we do not have to define a path for Composer
NodeJS is installed via the NodeTool@0 task, we can specify the version of Node we want to install
Node packages are installed and the JS bundle is built using the Npm@1 tasks. We need to define the command and path to files to each command (in this case we install and then run a custom build command for build). The path is by default $(Build.SourcesDirectory) which represents the root of the pulled git repository
After all dependencies are installed and the frontend bundle is built, we can copy the files to $(Build.ArtifactStagingDirectory). We are excluding the node_modules, .git and storage directories as these are no longer needed
Finally, we take the complete application files from the artifact staging directory, compress these into a tar archive and publish them. This will upload the tar to Azure Pipelines storage for later use in Release pipelines

If you need to add more tasks, the Assistant which can be found in the top right corner of the editor is very useful as it contains a list of usable tasks, you can also define the task values in a UI which will then be transformed into YAML representation.

After completing your pipeline, click Save and run button in the top right corner above the editor, this will commit the pipeline to your repo and run the pipeline. Ideally, it would complete on the first try, if not, open the build and search the task logs for errors. The pipeline logs should look like this:

Setting up the deployment

The deployment can be a little trickier depending on where your application is published. If you use shared hosting, Azure AppService or a similar service, the deployment would be pretty straightforward as you would only need to download the artifact and upload it via FTP or AzureRM to your destination.

For 'enterprise' use or for people who host applications on their own servers, this is where the fun begins. One of the best features of Azure DevOps CI/CD pipelines is the option to use self-hosted agents (or private agents as they are sometimes called).

This means that an agent (or multiple agents) which is used for the deployment is running directly on the application server. This has several advantages:

The communication is done in such a way that the self-hosted agent on your server communicates to Azure DevOps via an API. Therefore, in many cases it eliminates the need to have multiple ports open on the application server's firewall to be able to deploy your application there from a remote CI/CD server, thus eliminating possible attack vectors on your infrastructure
You also do not need to store credentials or SSH keys anywhere in the CI/CD tool as the agent runs directly on the machine as a regular user
The deployments via the Private agent also tend to be faster than deploying via SFTP/WinRM/Robocopy or other tools
These agents can be used free of charge (with no monthly limits on usage minutes or number of agents)

The release pipeline

Unlike the build pipelines, the release pipelines do not use YAML but rather a visual editor just like Classic pipelines. You can find release pipelines under Releases in the Pipelines submenu. From there you can create a New pipeline.

After creating the pipeline, you can Add an artifact, where you can select the desired artifact. For the source pipeline, choose the pipeline you've just build from the dropdown and set the source alias (this will be the alias which you'll use to reference the build artifact), for example, _build. After that, we'll need to define one or multiple release stages. These would normally be DEV, STAGING, UAT, PROD, etc. Stages then contain deployment tasks.

You can also use the YAML pipelines to deploy your application. This feature made it from preview to stable a few years ago but in my opinion, it is not as polished as the current Classic Releases (there are some caveats to managing your deployments this way). You can check out the YAML deployments documentation here if you are interested.

Using self-hosted agent

As stated before, for deploying to your own server, the recommended way is to use a self-hosted agent. This agent can be run in a Docker container or directly on the target system as a regular user. The agent can make use of utilities installed on the system which is helpful for the deployment.

The pipeline for self-hosted applications looks as follows:

A pseudo-representation in YAML would look like this:

steps:
- script: 'php artisan down'
  workingDirectory: '$(DeployDirectory)'
  displayName: 'Take app offline'
  continueOnError: true
- script: '[ ! -d "$(DeployTempDirectory)" ] && mkdir -p $(DeployTempDirectory); tar -xf $(System.DefaultWorkingDirectory)/_build/drop/drop.tar -C $(DeployTempDirectory)'
  workingDirectory: '$(DeployDirectory)'
  displayName: 'Extract artifact to temporary directory'
- task: CopyFiles@2
  displayName: 'Deploy application'
  inputs:
    SourceFolder: '$(DeployTempDirectory)'
    TargetFolder: '$(DeployDirectory)'
    OverWrite: true
- script: 'php artisan migrate --force'
  workingDirectory: '$(DeployDirectory)'
  displayName: 'Run migrations'
- script: 'php artisan up'
  workingDirectory: '$(DeployDirectory)'
  displayName: 'Start the application'

The pipeline also uses variables which are defined in the Variables section of the release. For each stage, a $(DeployDirectory) variable is defined as the path to the application deploy directory on the target system.

To install a self-hosted agent:

Go to Project Settings > Agent Pools in your DevOps project
Create a new Agent Pool
Click New Agent in the top right corner of the window
Follow the instructions on the screen

You can also install the agent as a Docker container, refer to this repo for more.

For PAT authentication, you will also need to generate a Personal Access Token, this can be done from the settings menu. The PAT needs to have permission to Read and manage Agent Pools, otherwise, it will not be able to register itself to the created agent pool.

You can also run the agent as a service, for Linux hosts, you would run these commands from the agent's install directory:

sudo ./svc.sh install $USER
sudo ./svc.sh start

After the agent is installed and running, you can begin using it in your pipelines. The agent can be selected from the Job settings inside a release.

Note that there might be additional configuration needed on the server for the deployments to be successful. You may have to add a .env file and change permissions on the deploy folder. An example of this would be the following:

export TARGET_DIR=/var/www/your_project

sudo chown -R $USER:www-data $TARGET_DIR
sudo find $TARGET_DIR -type f -exec chmod 644 {} \;
sudo find $TARGET_DIR -type d -exec chmod 755 {} \;

cd $TARGET_DIR

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

touch $TARGET_DIR/.env
# fill your .env file

Using Microsoft-hosted agent

If you are deploying to a managed hosting service via FTP or you need to deploy via SCP/SFTP to the target server, you can use Microsoft-hosted agents. Using these in the release pipelines also counts towards the monthly build-minutes limit.

If your application is hosted in Azure AppService, there are dedicated tasks for example the Azure App Service deploy task which uses a service connection to Azure to deploy your application to the AppService.

In any case, the pipeline would then have only one task, which would probably be the FTP Upload or the App Service deploy task. In case of deploying to managed hosting service via FTP, it would look something like this:

Note that in the aforementioned case, you would also need to set up the $(Password) secret variable.

Conclusion

In this article, I went through the steps to set up CI/CD pipelines for a Laravel application in Azure DevOps. The advantages and possible disadvantages of Azure DevOps as a CI/CD and project management tool were clarified.

For reference, you can find the complete Azure DevOps project here, and the repo is located here.

Thanks for reading...

Introducing ingoreinit - A CLI tool for creating gitignores

Dominik Zarsky — Sun, 23 Oct 2022 16:26:00 +0000

Let's talk generating .gitignore files - a file every git repo should have. Some tools for scaffolding projects like create-tauri-app or composer create-project initialize .gitignore for you. But what about applications which do not use these? Like when generating new solution in Visual Studio or creating a new Go app. Many developers tend to manually copy the ignore files from their previous projects or go to github/gitignore to get them. In my opinion, this is very tedious and can be achieved in a simpler and faster way - via the CLI.

This is where ignoreinit comes in.

The tool

I originally wanted to create a tool like this mainly for the aformentioned reasons - it is faster and more comfortable to get your .gitignore from the command line. And as somebody who is always working on new projects, I wanted to simplify my workflow as much as possible.

The tool itself is written in Go, leveraging a library called go-github to fetch gitignores. In the first iteration, it can either download a new gitignore file based on selected language and framework (for now it has to be one of the gitignore files present in the aformentioned github/gitignore repo) or replace existing gitignore by specifying new language and path of the ignore to be replaced.

The flow is as follows:

ignoreinit parses the CLI parameters
It fetches the list of all available gitignores from the repo
Determines whether a .gitignore is available for selected language or framework
If it is, ignoreinit downloads the ignore file and creates .gitignore with its contents in the selected directory

The flow is pretty simple. As is the main function which handles the fetching itself, I will include a snippet at the end of the article.

How to get and use ignoreinit

If you find the tool interesting, it can currently be installed in three ways. If you have Go already installed on your machine, you could just do go install github.com/loupeznik/ignoreinit@latest, this should automatically install it and add it to your $PATH (if you have path to Go binaries in your $PATH already). Cloning the repo and building the binary yourself is also a possibility.

If you are Go-less, you can always get it from the Releases page of the Github repo. Binaries for Linux, Windows and MacOS are available. Using the last method, you might want to add the binary to your $PATH (e.g. moving it for example to /usr/local/bin on Linux or appending the folder which the executable resides in to your PATH on Windows).

Usage is pretty straightforward:

ignoreinit <init|replace> <language> <location>

For example:

# Initialize a new .gitignore for Go in current directory
ignoreinit init go
# Initialize a new .gitignore for Python in different directory
ignoreinit init python C:\Dev\my-flask-api
# Replace gitignore in current directory
ignoreinit replace c++

Conclusion and future development

This article briefly introduced the ignoreinit CLI tool for generating .gitignore files conveniently from the commandline. In the future, I would like to enhance the tool to also support .dockerignore files, have more .gitignore repositories available and have the tool available in package managers like snap, apt or chocolatey for smoother installation experience.

If you've made it this far, thanks for reading. Until next time...

P.S. the aformentioned snippet:

func getIgnore(language string, location string, isNew bool) error {
    client := github.NewClient(nil)
    ctx := context.Background()
    options := &github.RepositoryContentGetOptions{}

    _, directoryContent, _, err := client.Repositories.GetContents(ctx, gitOwner, gitRepo, "/", options)

    if err != nil {
        return err
    }

    var url string

    for _, file := range directoryContent {
        if !strings.EqualFold(strings.Split(*file.Name, ".")[0], language) {
            continue
        }

        url = file.GetPath()

        break
    }

    if url == "" {
        return fmt.Errorf("could not find .gitignore for %s", language)
    }

    reader, _, err := client.Repositories.DownloadContents(ctx, gitOwner, gitRepo, url, options)

    if err != nil {
        return err
    }

    defer reader.Close()

    bytes, err := io.ReadAll(reader)

    if err != nil {
        return err
    }

    var file *os.File
    fullPath := path.Join(location, ".gitignore")

    if isNew {
        file, err = os.Create(fullPath)
    } else {
        file, err = os.OpenFile(fullPath, os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0755)
    }

    if err != nil {
        return err
    }

    defer file.Close()

    _, err = file.Write(bytes)

    if err != nil {
        return err
    }

    return nil
}

Cover image credit to Gabriel Heinzer on Unsplash.

This article was originally posted over at blog.dzarsky.eu.

Creating a Time-Triggered AWS Lambda Function

Dominik Zarsky — Fri, 06 Aug 2021 13:28:16 +0000

This article will cover basic steps for creating a time-triggered Lambda function. This can be useful if you want to check for something periodically (for example once per hour). You might want to check if your server is up, fetch data from an API and compare them to previously collected values and so on. The possibilities are endless with a serverless platform like Lambda.

What is AWS Lambda

Let's briefly touch upon what Lambda actually is and how you can access it. Lambda is a serverless platform offered by Amazon Web Services (AWS). By using Lambda, you eliminate the need to provision, set up and administer your own server, you just upload the scripts you want to run to Lambda and the AWS backend takes care of everything related to actually running your script. This is especially useful if you have small scripts which don't run long and provisioning a server just to run them wouldn't make much sense. With Lambda, you pay only for the resources/time said script consumes, as opposed to running it on a dedicated EC2 instance.

As part of the Always Free tier of AWS, you get 1 million requests per month for free on Lambda, which is pretty good. Accessing Lambda is easy, you may do it from the AWS Console or with a command line, for this article I'm going to be using the AWS Console as it is more of a straight-forward approach.

Creating the function

For the sake of simplicity, let's assume we want to create a function which gets values of Bitcoin, Ethereum and Dogecoin from the messari.io API every hour. It would also be nice to save these to a database. Let's also assume we have an instance of MongoDB up and running somewhere. An S3 bucket on AWS or any other database can also be used, you may also just log the values without storing them, that should be enough as a proof of concept.

I will be creating this function in Go, it is also possible to create Lambda functions in Python, .NET Core, Java, Ruby or NodeJS.

The code

First things first, let's get the code done. For creating a function in Go, you'll need the aws-lambda-go package, you can get it by invoking go get github.com/aws/aws-lambda-go/lambda from the command line. The function will probably work even without this library, but even if your script completes successfully, you'll get errors reported by Lambda (trust me, I've tried).

After that, it's just a matter of importing the rest of the libraries needed to make this work and implement the functionality we want. The main function's code would look like this:

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"
    "os"
    "time"

    "github.com/aws/aws-lambda-go/lambda"
    client "github.com/bozd4g/go-http-client"
    "go.mongodb.org/mongo-driver/mongo"
    "go.mongodb.org/mongo-driver/mongo/options"
)

type Coin struct {
    Status struct {
        Timestamp time.Time `json:"timestamp"`
    } `json:"status"`
    Data struct {
        Symbol     string `json:"symbol"`
        Name       string `json:"name"`
        MarketData struct {
            Value float32 `json:"price_usd"`
        } `json:"market_data"`
    } `json:"data"`
}

func main() {
    lambda.Start(handle)
}

func handle() {
    assets := [3]string{"btc", "eth", "doge"}

    httpClient := client.New("https://data.messari.io/api/v1/")

    db, err := mongo.NewClient(
        options.Client().ApplyURI(os.Getenv("MONGO_URI")))
    if err != nil {
        log.Fatal(err)
    }

    ctx, _ := context.WithTimeout(context.Background(), 10*time.Second)
    err = db.Connect(ctx)
    if err != nil {
        log.Fatal(err)
    }
    defer db.Disconnect(ctx)

    for _, asset := range assets {
        request, err := httpClient.Get(
            "assets/" + asset + "/metrics?fields=symbol,name,market_data")

        if err != nil {
            panic(err)
        }

        response, err := httpClient.Do(request)

        if err != nil {
            panic(err)
        }

        data := Coin{}
        err = json.Unmarshal(response.Get().Body, &data)
        if err != nil {
            panic(err)
        }

        collection := db.Database("coins").Collection("coins")
        result, err := collection.InsertOne(ctx, data)

        if err != nil {
            log.Printf("Could not save values for " + data.Data.Symbol)
        } else {
            log.Printf(
                "Saved data for " + data.Data.Symbol +
                    " as " + fmt.Sprint(result.InsertedID))
        }
    }
}

If it isn't apparent, I'll shortly explain what the code does. In the handle() function, it initializes the HTTP client for fetching the API data and the MongoDB client for storing it. It then fetches the data from the API, serializes it into the Coin struct which defines our structure of a cryptocurrency (or at least the data we need to fetch/store), then it stores the data in the database and logs the result. The main() function calls the handle() function and does it's Lambda stuff, pretty straightforward.

Note that an environment variable is being used to store the MongoDB connection string, this is important and will come into play when setting the function up in AWS Lambda control panel.

Lambda setup

Now that we are done with the code, let's go to the AWS Console and into Lambda. A new function can be set up here. Let's click Create function, select the Go runtime and let's name it CryptoRateFetcher. Then click Create function again.

You should land at your function's dashboard. Here you can upload your scripts, select triggers and events and configure your function.

First things first, let's build the script, upload it and set the MongoDB URI as a environment variable. You will need to build a Linux binary, as Lambda can only execute these. If you're on Windows, you can use WSL or Docker to create the binary. In the project's directory, we'll need to run:

GOOS=linux GOARCH=amd64 go build -o main .
zip main.zip main

In this example, I'll upload the .zip directly to Lambda, uploading it to S3 and running the function from there is also possible.

The image above shows the function dashboard where you can upload the zip. Note that the Handler is set to hello, this is a default for some reason and you will need to change it to main or however is your main function called. After uploading the code, head over to the Configuration tab and select Environment Variables. There you can add the MONGO_URI variable which will be consumed by the script on execution. You can now save the function by clicking Actions -> Publish new version in the upper right corner of the dashboard. You can now test the function in the Test tab, which should yield a success, if everything has been set up correctly. The output might look like this:

The Trigger

Now that we know our function is working, let's set the timed trigger to start our function every hour. Back on the main function dashboard, hit Add trigger on the left, a dropdown should appear. Choose Event Bridge and create a new Rule. A new form where you can configure your event should appear. Select Schedule expression as your Rule type and configure it accordingly. You can use regular CRON syntax or use rates. After that, click Add and you're pretty much finished.

The last thing to do is to wait for the results it yields. As you can see in the picture below, over the last several hours, we've fetched and stored multiple Bitcoin values, with the time interval being indeed one hour per record.

Wrapping up

In this article, I've demonstrated an easy way to deploy a rather simple script to Amazon Web Services' serverless platform AWS Lambda. I've also touched upon what Lambda actually is and what pros there are to use it with AWS Always Free tier. A way to set up a timed trigger to start the script in a certain interval was shown.

The examples in this article were very simple, indeed, and you can run much more complex scripts or programs in Lambda, there are also options to invoke the function via REST API which were not touched upon in this article, but I may come back to them on a later date. The example script shown in this article will be available in this repo over at my GitHub. If you found this article interesting, you might also want to check out my other Lambda function written in Go which checks if array of user-defined hosts (webservers) are up, in this repo.

Thanks for reading, until next time...

This article was originally published on my personal blog.

Deploying a Laravel application to GCP with Bitnami LAMP

Dominik Zarsky — Sat, 03 Jul 2021 12:57:27 +0000

In this article, I will be going through the process of Laravel application deployment, namely to Google Cloud Platform (GCP). This article will cover the basics of GCP as a Cloud Service Provider, the steps of setting up a new Virtual Machine via the Google Cloud Console and deploying your application onto it.

Google Cloud Platform introduction

First, let's talk about what the GCP is and what it offers. Google Cloud Platform is a cloud service provider run by Google and is very similar to other cloud service providers like AWS or Oracle Cloud Infrastructure. It offers services like the Compute Engine where you can deploy virtual machines, various tiers of Cloud Storage which offers AWS S3-like storage buckets, variety of serverless solutions and so on. GCP also offers a generous free tier, with $300 in free credits you may use in your first 3 months on any service, as well as forever free services beyond this trial period. These include for example 1 VM (F-1 micro only in US datacenters), 5GB of Cloud Storage or Firebase functionality (up to monthly limits). You can read more about the free tier here.

To get started with the GCP, you'll need a Google account. You will also need to register an account with the GCP. The registration process is fairly easy and includes filling various information about yourself, such as billing information, as you might be accustomed to when setting up an account with any Cloud Service Provider.

Creating a Virtual Machine

To spin up a new Virtual Machine, head over to the Cloud Console, then to Compute Engine and select Create Instance. For deploying any PHP application to the cloud (be it Laravel, Symfony or any framework-independent application), I tend to use the Bitnami LAMP cloud images which can, fortunately, be found on AWS, GCP and Azure marketplaces. I have very good experience with these images, as they tend to be secure and have everything you'd need for hosting a PHP web application already preinstalled. You can find out more about these here.

In the Create Instance dialog, several image options pop up on the left-hand side of the screen. We'll go to Marketplace and search for LAMP Certified by Bitnami image. A listing for LAMP Certified by Bitnami should appear. Upon clicking the listed image, you'll be redirected to the image's description screen. Once there, click Launch, this takes you back to the Virtual Machine configuration screen as seen below.

You may set machine parameters here, the main ones to focus on are the Deployment Zone, Machine Type and Disk Size. As you can see in the screenshot above, I've chosen the F-1 micro type as it is powerful enough for the purpose of this showcase, if you're running a larger application, be sure to check machine types with more RAM and CPU. Just a reminder - the F-1 micro instances as part of the forever free tier are applicable only in selected US regions (us-east-1, us-west-1 and us-central-1 as to my knowledge), if you deploy these anywhere else, you will be charged.

As to other settings, you can allow traffic on ports 80 and 443 on this screen or you can do it later by adding firewall rules to this machine. For convenience, it is better to tick the Allow HTTP/HTTPS traffic options from this screen directly. Port 22 should also be allowed by default. After you're finished configuring the instance, accept the terms and click Deploy. The deployment might take a little while, this would depend on your selected datacenter, machine type, and so on.

Accessing the Virtual Machine

After the machine is successfully deployed, you should arrive on the following screen.

From here, you might want to take a note of the IP address and the admin password. Accessing the VM from here is simple, just click SSH underneath the basic machine information table, a new browser window should pop up and you should be connected to the VM via SSH. You can also connect to the VM via another SSH client like Termius or with gcloud CLI, instructions for these methods should be available in the attached documentation.

Setting up the VM

As we have all needed software like PHP, Apache 2, MariaDB (MySQL), Composer and Git already installed, we'll just need to set these up properly to get our application running. The only thing you might need is NodeJS/NPM as most of Laravel applications make use of NPM to install JavaScript packages like Laravel Mix. To install NodeJS fast and easy, we'll make use of nodesource. Bitnami LAMP currently runs Debian 10, thus we'll import a Debian NodeJS 16.x source and install it via apt.

sudo curl -fsSL https://deb.nodesource.com/setup_16.x | sudo bash -
sudo apt install -y nodejs

The Database

Let's set up a database first, we'll make use of the admin password we've been given. The following flow will create a database and a user for your application.

dominik_zarsky@lampstack-2-vm:/home/bitnami$ mysql -uroot -p
Enter password: <your_admin_password_here>
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.3.29-MariaDB Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> CREATE DATABASE laravel;
Query OK, 1 row affected (0.021 sec)
MariaDB [(none)]> CREATE USER 'laravel'@'localhost' IDENTIFIED BY 'test123';
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> GRANT ALL PRIVILEGES ON laravel.* TO 'laravel'@'localhost';
Query OK, 0 rows affected (0.015 sec)
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.017 sec)
MariaDB [(none)]> exit;
Bye

The Application

For the purpose of this showcase, I'll clone the Laravel Boilerplate application from GitHub, as I presume you'd be installing your own the same way. If you're not using Git, you may want to use SCP to copy your application's files over to the VM (you'd need to download the machine's SSH keys for that, instructions for this could be found in this documentation).

Let's hop on over to /opt/bitnami which is the default directory for all preinstalled Bitnami software and files. It is customary to create a projects directory here, this will be the directory where all custom web applications would be placed. The following commands can be used as a general flow for setting up the whole application. If you encounter permissions problem, execute the following commands as sudo or change the permissions to the projects directory.

cd /opt/bitnami/
mkdir projects && cd projects
git clone https://github.com/rappasoft/laravel-boilerplate
cd laravel-boilerplace
cp .env.example .env
composer install
npm install
npm run prod
php artisan key generate
php artisan storage:link
sudo chown -R daemon:daemon /opt/bitnami/projects/laravel-boilerplate/storage
sudo chown -R daemon:daemon /opt/bitnami/projects/laravel-boilerplate/bootstrap

Now we'll need to update the .env file's database settings for the database we've created earlier.

....
# Database
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=test123
....

Finally, we can migrate and seed the database.

php artisan migrate
php artisan db:seed

The Server

Now the application is all set up, the only thing that is left to be done is to set up the Apache 2 webserver itself. For that, we'll need to set up a new Virtual Host, we can achieve this by going to the Apache2 configuration directory and creating a new VHOST entry. Let's create a laravel-boilerplate-vhost.conf in /opt/bitnami/apache2/conf/vhosts directory. You might do this with Vim or nano. The vhost needs to be configured like this:

  <VirtualHost 127.0.0.1:80 _default_:80>
    ServerAlias *
    # ServerName yourdomain.com
    DocumentRoot /opt/bitnami/projects/laravel-boilerplate/public
    <Directory "/opt/bitnami/projects/laravel-boilerplate/public">
      Options -Indexes +FollowSymLinks -MultiViews
      AllowOverride All
      Require all granted
    </Directory>
  </VirtualHost>

To apply the changes, we'll restart the Apache 2 webserver by running

sudo /opt/bitnami/ctlscript.sh restart apache

It works

After restarting Apache 2, head over to the VM's IP, you should see your application up and running, just like the sample Laravel Boilerplate application shown below.

Next steps

Up next, you might want to set up a static IP for your instance, you can do that from the VPC network section under Networking in the left-hand side menu. In that section, choose the External IP addresses tab. You should see the following screen, where you can change the IP type from ephemeral to static. That way, the IP won't change over time and you can happily assign a domain name to this machine.

If you'd like to get a free Let's Encrypt SSL certificate, the Bitnami LAMP image is equipped with the bncert tool which makes it easy to generate and configure an SSL certificate for your website. You can run the bncert tool with

sudo /opt/bitnami/bncert-tool

You can learn more about it in Bitnami's documentation.

Wrapping up

In this article, I've summarized the use-cases for the Google Cloud Platform, then a way to spin up a Bitnami LAMP Virtual Machine instance on the GCP by using the Google Cloud Console was shown. After that, we've set the instance up to a state when we could deploy and publish a sample Laravel application on it, this included setting up a MySQL database, the application itself and an Apache 2 web server. I hope this article helped some of you with deploying your application to the GCP. If not, you may also want to check out the GCP VM Documentation and Bitnami documentation. Until next time...

How To Create Multiple Laravel Models With A Single Command

Dominik Zarsky — Thu, 01 Apr 2021 14:47:08 +0000

Have you ever encountered the need to create multiple artisan objects, like Eloquent models, controllers or Livewire components at one moment? When starting a new project, this is a very likely situation. Solving it by running command after command like php artisan make:model $NAME -msc over and over again isn't a particularly good idea, in my opinion, as it takes a lot of time. As far as I know, there aren't any command-line tools to remediate this problem, so I decided to make one.

Solving the problem

The obvious solution to this is to take a OS-native shell, like Bash for Linux or Powershell for Windows (although you can use PowerShell on Linux as well), and write a script to automate the tedious task of running the aforementioned artisan commands by hand. As I was on Windows at the time of getting the idea of this script, I'm going to present the solution to the problem in Powershell. Note that it can also be easily converted to a Linux shell script and I'm surely going to do that some time in the future.

This implementation of the script contains a solution to batch Eloquent model creation with additional (optional) parameters like migrations, controllers, seeders and factories connected to the model. Let's take a look at the final script:

Note: The full version of this script is also available at my GitHub.

# artisan-model-generator.ps1

if (!(Test-Path ".\artisan" -PathType Leaf)) {
  echo "ERROR: Artisan not found in this directory"
  exit
}

$input = Read-Host -Prompt "Enter model names separated by commas"

if (!$input) {
  echo "ERROR: No model names entered"
  exit
}

echo "Enter switches to create additional classes (like -msfc)"
$switch = Read-Host -Prompt "Enter the desired switches"

if (!$switch) {
  echo "WARNING: No switch selected"
} else {
  if ($switch -notcontains "-") {
    $switch = "-" + $switch
  }
  if ($switch -notmatch "[mscf]") {
    echo "ERROR: The switch can contain only [mscf] characters"
    exit
  }
}

$input = $input -replace '\s',''
$switch = $switch -replace '\s',''
$models = $input.Split(",")

foreach ($model in $models) {
  echo "Creating model $model"
  php artisan make:model $model $switch
}

The snippet above is a simplified version of the script you can get in the GitHub repo linked above it.

What the script does

The script works as follows:

It checks if the artisan script is present, if it isn't, the script exits
It prompts the user for input, in this case, the names of the models the user wants to create
If the input is valid, it prompts the user for additional components to create
If input is empty, only the model is created, otherwise, the script takes the entered input as artisan make:model switches. It also checks if the entered switches are valid
After this, white spaces are removed from the input strings and the models array is created from the first input string (model names)

After these steps are complete, the script starts to generate our models with the desired names and switches. The output of the command would look like this:

PS C:\Users\domin\Documents\www\laravel-test> .\artisan-models.ps1
Artisan model generator
Enter model names separated by commas: Person, Article, Item
Enter the desired switches: ms
Creating model Person
Model created successfully.
Created Migration: 2021_03_31_112410_create_people_table
Seeder created successfully.
Creating model Article
Model created successfully.
Created Migration: 2021_03_31_112527_create_articles_table
Seeder created successfully.
Creating model Item
Model created successfully.
Created Migration: 2021_03_31_112533_create_items_table
Seeder created successfully.

In the snippet above, we're creating 3 models - Person, Article and Item. With these, we are also creating a migration and a seeder. The artisan command php artisan make:model $ITEM -ms is run by the script and we've saved some time. It's a win-win situation.

Wrapping up

This has been just a quick article about a script I've made a couple of days back, just to show you how easy it can be to batch generate a bunch of Eloquent models. Of course, this script can be taken a bit further, maybe with better exception handling or by expanding it beyond just generating models. If you'd like to expand upon this basis, feel free to fork the aforementioned repo and submit a pull request.

Setting Up API Call Limits In Laravel - Part 2

Dominik Zarsky — Wed, 24 Mar 2021 16:46:30 +0000

In this second part of my API request limiting series, I'll dive into building a custom middleware for tracking user's requests to our API endpoints and setting limits according to the user's privileges. As a reminder to the previous part, we're building a public API for our users to fetch data, these users are split into various subscription tiers and for some tiers, we need to limit their access to the API over time. Now that we're all caught up, let's get started.

How does this work

For this to work properly, we're going to need to take into account three parts of our application - the API, the database and the middleware. This method is going to be slightly different than the one used in the previous article, as we are going to store information about the user's request to the database, rather than doing the limiting under the hood using a rate limiter. This way, we'll have more information about the request for future use, as you'll see at the end of the article.

Setting up the database

First of all, we need to set up a database table and Laravel model for our requests. We'll achieve this with one artisan command.

php artisan make:model Request --migration

This will create the Request model and the create_requests_table migration. In my database, I have columns for request id, API token via which a given endpoint was called, the id of the user that called that endpoint, date and time of the request and the URI the user called. The token and the user id reference the same row in the users table, so the second one is kinda redundant, I didn't want to address this problem when I was creating the API though, so we'll go with what we've got. The migration function looks like this:

    public function up()
    {
        Schema::create('requests', function (Blueprint $table) {
            $table->id();
            $table->string('token');
            $table->integer('user_id');
            $table->datetime('date');
            $table->string('content');
            $table->foreign('user_id')
                       ->references('id')
                       ->on('users');
            $table->foreign('token')
                       ->references('api_token')
                       ->on('users');
        });
    }

For the model, it is pretty straightforward. We're disabling timestamps because the rows in the table will not be updated and we've already supplied the request datetime in the date column. We're also making every column except id fillable.

// app/Models/Request.php

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Request extends Model
{

    public $timestamps = false;

    protected $fillable = [
        'token',
        'user_id',
        'date',
        'content'
    ];
}

Setting up the middleware

Now that we have the database layer set up, we can go ahead and create the middleware. We're going to be referencing the User and Request models as the request is tied to the user who is calling the API via their API token. As in the previous part, we are using bearer tokens to authenticate users. To continue the subscription-based public API model we've discussed in the last article, we'll set request limits to certain groups of users. This time, free-tier users are limited to one request to the API per day, subscribed users can make unlimited number of requests. Let's see the middleware first:

// app/Http/Middleware/AccessLevel.php

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use App\Models\User;
use Illuminate\Support\Carbon;
use App\Models\Request as ApiRequest;

class AccessLevel
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle(Request $request, Closure $next)
    {

        $token = $request->bearerToken();
        if (User::where('api_token', $token)->exists()) {
            $user = User::where('api_token', $token)->first();
        } else {
            return response()
                ->json(['error' => 'Bad token'], 401);
        }

        if ($user->access == 0) {
            if ($this->checkLimit($token, today())) {
                return response()
                ->json(['error' => 'Daily call limit exceeded'], 429);
            }
        }
        ApiRequest::create([
            'token' => $token,
            'user_id' => $user->id,
            'date' => Carbon::now(),
            'content' => $request->url()
        ]);
        return $next($request);

    }

    private function checkLimit($token, $date)
    {

        if (ApiRequest::where('token', $token)
            ->where('date', 'like', $date->format('Y-m-d') . '%')
            ->exists()) {
                return true;
            } else {
                return false;
        }
    }
}

There is much going on in this middleware, let's digest it a little bit. The request goes to a given API route and the middleware fires up. From the request, a bearer token is extracted and checked against the users table. If a user with given token exists, the middleware registers the user into a variable and continues to do other checks, however if a user with this token doesn't exist, the middleware returns a 401. When this check is complete, the middleware checks the user's Access Level. If the user is a free-tier user, the checkLimit() method fires up and checks if a user has made an API call today. The check is of course done via the requests table. If the user has made a request today, the middleware returns a Too many requests error.

If no error was triggered, the request is stored in the database for future reference (either for the middleware or for statistical reasons).

As usual, we need to register this new middleware in app/Http/Kernel. You should register it in both the api middleware group and $routeMiddleware. If you do not want this restriction to fire up on all of your API routes, register it only in the $routeMiddleware array. I have mine registered like this:

// app/Http/Kernel.php

<?php

...
protected $middlewareGroups = [
    'web' => [
        ...
    ],
    'api' => [
        \App\Http\Middleware\ForceJson::class,
        \App\Http\Middleware\AccessLevel::class,
        'throttle:api',
        \Illuminate\Routing\Middleware\SubstituteBindings::class,
    ],
];

protected $routeMiddleware = [
    ...
    'access.level' => \App\Http\Middleware\AccessLevel::class,
];

If you choose not to register the middleware in the api middleware group, you will also need to register it in your routes/api.php file. Let's test the middleware to make sure it works...

As you can see in the picture above, we've only managed to get one request through before getting the Too many requests error when we supplied a non-subscribed user's token, thus fulfilling our goal.

Using the collected data

As I've used this technique to limit API requests for users on my own site - OnlyResultz, I wanted to display relevant API usage metrics to my users via the user's dashboard. For that use case, I displayed only daily, monthly and lifetime requests, but more ways to use the collected data exist, for your users and your application's administrators alike. An example of such functionality in Blade can be found in this Gist.

And the end result looks like this:

In the blade file above, we are supplying the $requests variable, which uses the Request model to fetch relevant requests for the user. The individual metrics are processed inside the blade file and served to the user in a readable form.

Wrapping up

This has been it for the Setting Up API Call Limits In Laravel series. Check out the previous article in the series if you haven't yet. In the other article, I explain how to use Laravel's built-in Rate Limiter to achieve similar result to that which we've seen in this article.

Until next time.

Cover image by Mohamed Hassan from Pixabay

Building an Anonymized Website Visitor Counter in Laravel

Dominik Zarsky — Mon, 15 Mar 2021 18:23:38 +0000

In this day and age, we all need to have some sort of idea of our website's performance and the least we can do for this is to somehow track our audience - the visitors of our webpage. This can be done by using a third-party service like Google Analytics, Cloudflare or other services. These, unfortunately, expose our visitors to cookies and come in with a whole set of challenges pertaining to GDPR and other privacy-regulating laws in the EU and also other countries of the world. Thought this approach might be the easiest one when it comes to implementing such functionality into your website, you might have to deal with the legal side of things (like privacy policy, cookie consent, and more) on top of it. If you are already using cookies in some capacity other than for example session cookies or XSFR tokens (like in basic Laravel apps), you may not have a problem with this, but if you want to be free of these third-party cookies, I've got another option for you.

The Concept

The concept of this approach to visitor tracking is fairly simple. The goal is to have an anonymized record of unique visits of our website for each day. I'm going to show an example of this in Laravel, but this concept can be taken to other frameworks and languages. I've tested this in regular PHP, it can be also done in .NET or Python (with some modifications of course).

The main thing that makes this method more privacy-compliant than using those third-party tools is anonymization. Almost no data about the user is being collected on the server-side. We only collect the date of the visit, and the visitor's IP address which is then hashed and only the hash is stored in the database.

The Execution

As simple as the concept was, the execution is keeping it simple as well. For this to work, we are going to need to write a custom middleware which determines if a visitor has already been recorded for a given day. If the visitor hasn't been recorded, it inserts their visit into the database, otherwise, the visit is not registered. The middleware checks the visitor's IP hash against the hash in the database to determine if the visit had been recorded before. Now let's look at the code of this middleware:

// app/Http/Middleware/CountVisitor.php

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use App\Models\Visitor;

class CountVisitor
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle(Request $request, Closure $next)
    {
        $ip = hash('sha512', $request->ip());
        if (Visitor::where('date', today())->where('ip', $ip)->count() < 1)
        {
            Visitor::create([
                'date' => today(),
                'ip' => $ip,
            ]);
        }
        return $next($request);
    }
}

This one is pretty straightforward and does exactly what has already been described at the start of this part of the article. We are only inserting today's date and SHA-512 hashed IP address of the visitor into the database. You could hash it with another hashing algorithm like bcrypt or SHA-256, but I went for SHA-512 in this case, though they all are fairly safe ways to hash the data.

Of course, the middleware also needs to be registered in app/Http/Kernel as a route middleware. I've registered it like this:

// app/Http/Kernel.php

...
protected $routeMiddleware = [
    ...,
    'visitor' => \App\Http\Middleware\CountVisitor::class
];

Now, you can add this to your web routes as a middleware. Alternatively, you might want to apply it to all web routes, in that case, you would register this middleware in the web middleware group in app/Http/Kernel. I usually don't want this to fire up on administrative routes though, so I use this middleware only for publicly accessible pages. The routes then looks like this:

// routes/web.php

<?php

use Illuminate\Support\Facades\Route;

Route::name('front.')->middleware('visitor')->group(function() {
    Route::get('/', 'FrontpageController@index')->name('index');
    ...
});

Visualizing the collected data

For this article, I'm not going to go into detail about visualizing the data we've collected as that could be a whole separate article. I'm just going to leave a link to a GitHub gist containing the code needed to visualize the data. The final result can be seen below.

Here is the source

The pros and cons

This method has several advantages and disadvantages, let's explore them here.

The pros

Anonymized data
Simple solution
Simple implementation
First party
No cookies

The cons

The collected data doesn't reflect the visitor's behavior on the website (e.g. time spent on the webpage, visited pages, etc.)
You have to write your own front-end to visualize the data
The database size might get quite big if you have a lot of traffic and the queries might get slow over time

These are more or less the biggest advantages and disadvantages of using this approach.

Wrapping up

This has been a showcase of a simple way of counting your website visitation by using a Laravel middleware. Note that this has only been tested on applications with about 50 unique visitors per day which I consider a small sample size. I am not very sure how viable would this approach be for a bigger project, but if you want to give it a fair try, go right ahead.

Cover photo by Carlos Muza on Unsplash

Setting Up API Call Limits In Laravel - Part 1

Dominik Zarsky — Tue, 09 Mar 2021 16:53:40 +0000

In this two part series of articles, I'll go through two ways to set up a request limit for your API based on the calling user's access level. This is extremely useful for any subscription-based API where you want to limit user groups to a specific number of API calls per a certain amount of time.

This part is going to be focused on using Laravel's built in Rate limiters, the second one will dive into creating a custom middleware to enforce the set limits.

Using a Rate Limiter

The simplest way to achieve this goal is to set up a rate limiting service which is built into Laravel and enabled by default for API middleware-restriced routes. The default limit is set to 60 requests per minute. The configuration can be changed in /app/Providers/RouteServiceProvider in the configureRateLimiting() method. This is the default:

protected function configureRateLimiting()
{
    RateLimiter::for('api', function (Request $request) {
        return Limit::perMinute(60);
    });
}

If you wanted to disable the default limit (which I wouldn't recommend as you would allow users to make unlimited requests to your API endpoints which may lead to overloads), you may do return Limit::none(); in this function, or you could remove this throttle from the api middleware group in /app/Http/Kernel.

Defining a custom rate limiter

In the configureRateLimiting() method, you can define more rate limiters. Let's make a limiter called matches which is going to limit calls to API route for fetching results from various football matches.

For this use case, let's say we have 3 types of users, an unregistered visitor, a registered user with a free account and a registered user who has subscribed to our service. The first one isn't registered, thus doesn't have an API token, therefore they cannot access our API, the second one has an API access token, but their request limit is one request per hour, the subscribed user can make unlimited number of calls to the API. We will be using the following variables:

Access Level - Category the user belongs to, 0 is a free account user, 1 is a subscribed user. This is represented by the access column of the users table in the database
Bearer Token - API token type for request authentication which is represented by the api_token column of the users table in the database, every user has a unique token

Now let's put it all together.

//RouteServiceProvider.php
protected function configureRateLimiting()
{
    RateLimiter::for('api', function (Request $request) {
        return Limit::perMinute(60);
    });

    RateLimiter::for('matches', function (Request $request) {
      $user = User::where('api_token', $request->bearerToken())
              ->first();
      switch ($user->access) {
        case 0:
          return Limit::perHour(1)->response(function () {
            return response()->json(
              ['error' => 'Request limit exceeded'],
              429
            );
          });
          break;
        case 1:
          return Limit::none();
          break;
      }
    });
}

//routes/api.php
Route::middleware(['auth:api','json.force','throttle:matches'])
->get('test', 'ApiController@testMatches');

Now that we have successfully set our own limit, we can disable the original api rate limiter, as our subscribed users would still be limited by it, as you can see below.

The script used for testing the API can be found here

To achieve this, we can simply set the API rate limiter to no limit, alternatively, we could disable the throttle:api in the api middleware group in /app/Http/Kernel altogether.

Next up

Next time, I will be showing you how I tackled the request rate limiting problem myself the first time I encountered the need to limit the access to my API. This option is a little bit more tricky than the one I've shown you today, as it involves creating a set of custom middleware and working with the database a little more.

To be continued...

How To Backup Your VS Code Extensions And Settings

Dominik Zarsky — Tue, 02 Mar 2021 17:14:11 +0000

Backup your Visual Studio Code extension list and configuration files using Linux terminal.

Having the same working environment across multiple machines is always a good thing. This might be a case for your system configuration files (dotfiles) and your development tools alike. What I'm going to show you is a simple script that can help with the task of backing up your Visual Studio Code settings and extensions for use on your secondary PC, virtual environment or even your computer at work.

Setting up the backup

For this article, I'm going to suppose that you have VS Code already installed on your system and want to backup the settings and extensions you've spent some of your precious time setting up. We'll be using the old trusty Linux terminal magic and VS Code's command line utility code.

Our basic command for exporting the list of extensions is going to look like this:

code --list-extensions | xargs -L 1 echo code --install-extension

The code --list-extensions command exports the list of installed VS Code extensions which we then pipe into xargs, this transforms each extension's name into an extension install command. The output of this command looks like this:

code --install-extension anseki.vscode-color
code --install-extension autsenc.laravel-blade-spacer
code --install-extension Dart-Code.flutter

As you see we've successfully transformed the extension names to installation commands via xargs. You can output these into a file like this:

mkdir /home/$USER/code-backup && cd /home/$USER/code-backup
code --list-extensions | xargs -L 1 echo code --install-extension > ext

Now we also need to export the configuration files. These usually reside in your .config directory. The config files are saved in JSON format, so to back these up, you would simply tar them and save them somewhere in the cloud. Alternatively, you could push these into a Git repo.

cd /home/$USER/.config/Code/User
tar -czf code-config.tar.gz *.json
mv code-config.tar.gz /home/$USER/code-backup

In your code-backup folder, you should have your config files in a tar archive and your extension install script as ext. If you want to restore these on another machine, you'd just copy the code-backup directory's contents over and reverse the process shown above (that is, untar the config files into VS Code config directory and run the ext script)

Wrapping up

This was just a basic example of backing up your files. If you don't fancy writing backup scripts, you can check out my own full and a little enhanced implementation of this backup workflow over here. There is also a VS Code extension for synchronizing your settings called Settings Sync that synchronizes everything for you into a GitHub Gist.