DEV Community: borisuu

Deploying Python projects to air-gapped systems

borisuu — Fri, 27 Oct 2023 09:44:00 +0000

Motivation

A lot of times in the real world we have to deploy Python projects behind a company firewall, restricted systems or even an air-gapped system. This is most certainly a big hassle for most people.
I've found a pretty good setup which allows us to develop using modern tooling like poetry, but also deploy to any system without the need to pull any packages from the internet.

Project setup

The project is setup as follows

airgap/
├── airgap/
│   ├── __init__.py
│   └── main.py
├── poetry.lock
├── pyproject.toml
├── README.md

and we're pulling some dependencies into our project (I've used arrow which is an awesome date and time manipulation library):

[tool.poetry]
name = "airgap"
version = "0.1.0"
description = "A project running on an air-gapped system."
authors = ["..."]
readme = "README.md"

[tool.poetry.dependencies]
python = "^3.10"
arrow = "^1.3.0"


[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

We can have as many dependencies as we want, but for demonstration purposes I'll keep it short.

Preparation before distribution

We'll need to generate a requirements.txt file for our next steps. Let's use poetry to do that:

EDIT 2025-03-06: poetry doesn't ship with the export command by default any more. You'll need to install a plugin for that:

poetry self add poetry-plugin-export

There are also other options to do that, so make sure to check out the docs on the export command

poetry export -f requirements.txt -o requirements.txt

Command breakdown:

export the command used by poetry to convert the pyproject.toml file
-f: the format to use, only contstraints.txt and requirements.txt supported
-o: the name of the output file

After running you'll get a requirements.txt similar to this one (except the hashes which I've omitted for brevity):

arrow==1.3.0 ; python_version >= "3.10" and python_version < "4.0"
python-dateutil==2.8.2 ; python_version >= "3.10" and python_version < "4.0"
six==1.16.0 ; python_version >= "3.10" and python_version < "4.0"
types-python-dateutil==2.8.19.14 ; python_version >= "3.10" and python_version < "4.0"

Now comes the funky part. We'll create wheels from these dependencies and store them locally. We'll use pip to get the wheels:

pip wheel --no-deps --wheel-dir ./wheels -r requirements.txt

Command breakdown:

wheel: the pip command used to generate wheels docs
--no-deps: do not install dependencies (we've already got them all in the requirements.txt)
--wheel-dir: the directory to store the wheels (doesn't have to exist, it will be created for you)
-r: which requirements file to use

Our requirements.txt includes hashes, which means that pip wheel will imply the --require-hashes option. In turn this will verify the packages when installing.

Now our directory wheels will hold four packages (the ones from the requirements.txt). The final part is our own package source. We'll use poetry to build the wheel and place it in the wheels directory.

poetry build && mv dist/*.whl ./wheels

Command breakdown:

build: the poetry command which builds our project
mv: move files
dist/*.whl: source all files ending in .whl in the dist/ directory
./wheels: the destination for the sourced files

At this point we're done with the preparation. Just zip the ./wheels directory and distribute it to your air-gapped server. We'll just create a zip of the files:

zip -r airgap-dist-0.1.0.zip ./wheels/*

Command breakdown:

-r: compress the archive
iargap-dist-0.1.0.zip: name of the compressed archive
./wheels/*: the sources to put in the archive

Deployment

Get your zip to your air-gapped system, unpack it and install. The best-practice I stick to is to use the /opt directory to deploy custom software. Let's put it there:

mkdir /opt/airgap
unzip airgap-dist-0.1.0.zip -d /opt/airgap

Note: you might have to run the mkdir command using sudo. It's very dependant on your setup, user, OS version etc.

Just as an example you might need to do this:

sudo mkdir /opt/airgap
sudo chown youruser:yourgroup /opt/airgap
sudo chmod 755 /opt/airgap

Now in general I wouldn't advocate to install any project in the global Python site, but since we're striving for simplicity we'll do that. The next step is very easy, install our wheels:

pip install --no-cache /opt/airgap/wheels/*

Bonus

Just in case you want to use venv you can do the following:

python -m venv /opt/airgap/venv

Command breakdown:

-m venv: tell Python to use the module venv (should be installed by default)
/opt/airgap/venv: the location where to create the virtual environment, note that the directory name venv is just a convention, but you can use any name you like.

Activate the newly created virtual environment:

source /opt/airgap/venv/bin/activate

And then do the install:

# verify you're using the venv pip
which pip
$ /opt/airgap/venv/bin/pip

# install your packages
pip install --no-cache /opt/airgap/wheels/*

Note: to exit the virtual environment you can run deactivate in your terminal. It's a command automatically available as soon as you activate a virtual environment

Conclusion

We've seen how to extract the dependencies from our new pyproject.toml file, build wheels and zip them up for distribution. Consequently how we can deploy our project to our air-gapped system. Happy coding!

Setup Vite + Vue.js + Docker

borisuu — Wed, 25 Oct 2023 08:15:57 +0000

Introduction

Two things annoyed me on my last project. First, I had to use VITE_ prefixes on my environment variables in my .env file and second, I had to repeat myself on occasion when doing so.

I also wanted to avoid having to copy my main .env file to the frontend directory when developing locally or use the env_file option in the docker-compose.yaml configuration.

All this led me down a rabbit hole, where I finally came up with a solution. Come with me on this crazy ride and let's discover what I had to do, in order to achieve this...

TL;DR;

The reason I couldn't build is that the env_file and environment options in the docker-compose.yaml provide environment variables only in the finished container, not for the intermediate ones. Using ARG and ENV directives in the Dockerfile fixes that.

This is most relevant for multi-stage builds, or when your builds don't use sources you've already built locally.

# Dockerfile
...
# accept the environment variables from outside
ARG VITE_BACKEND_URL
ENV VITE_BACKEND_URL=$VITE_BACKEND_URL
...

# docker-compose.yaml
...
services:
  frontend:
  build:
    context: frontend/
    arguments:
      # inject the value provided by your root .env file, or an environment variable
      - VITE_BACKEND_URL=${VITE_BACKEND_URL}
  backend:
...

# vite.config.js
...
import vue from '@vitejs/plugin-vue';

export default defineConfig(() => {
  return {
    plugins: [vue()],
    define: {
      // this is necessary to avoid compile errors
      VITE_BACKEND_URL: JSON.stringify(`${process.env.VITE_BACKEND_URL}`),
    }
  }
});
...

# .env

VITE_BACKEND_URL=https://backend.test

The Problem

The main problem originates in Vite, which uses static variable replacement in its config when building for production (also in development, although it's a bit more lenient).

Production replacement of env variables in Vite

Basically whenever you do something like this in Vue.js with Vite:

<script>
  const backendUrl = import.meta.env.VITE_BACKEND_URL;

  axios.get(`${backendUrl}/api/resources`).then(...);
  ...
</script>

You'll encounter no errors when building but will be greeted by a nice call to undefined/api/resources, when you try to use your backend.

Mostly you'll have a .env lying around, which will be included in development mode, thus postponing the pain until you decide to build for production.

The failed solution

After a couple of months of development, it came time to start building for production and testing in production-ready environments. To my surprise nothing worked in the frontend - all the services needed to operate were undefined. After some googling around I came across the issue subtly described on the Vite homepage Vite config.

At first, I thought the solution would be to just use the define value in the vite.config.js:

import vue from '@vitejs/plugin-vue';
import { defineConfig } from "vite";

export default defineConfig(() => {
    return {
        plugins: [vue()],
        define: {
            VITE_BACKEND_URL: 'http://backend',
        }
    }
});

which works, because it's a static value (RHS of the definition). Optimistically, I then tried to replace it with the value from the .env file:

import vue from '@vitejs/plugin-vue';
import { defineConfig, loadEnv } from "vite";

export default defineConfig(() => {
    // The first argument is `mode` which is irrelevant for us.
    const env = loadEnv('', process.cwd());
    return {
        plugins: [vue()],
        define: {
            VITE_BACKEND_URL: env.VITE_BACKEND_URL,
        }
    }
});

This was, however, unsatisfactory, as I'd have to include an .env file of some sort.

Then I tried using the process.env object to get the values without loading any files. Sadly the
environment variables were always empty, although I was using the env_file option in my docker-compose.yaml config. The reason behind that is that environment variables are passed from Docker only to the finished container, so at build time we don't have access to them. That's when I started digging even deeper, trying to fix this.

The real solution

It turned out that the env_file option exposes the environment variables from my main .env, but only for the finished container. I wanted to use the variables during the build stage in an intermediate container. In order to make that work, we'd have to load the variables as ARG in the Dockerfile.

For example:

...
ARG VITE_BACKEND_URL
...

services:
  frontend:
    build:
      context: frontend/
    args:
      - VITE_BACKEND_URL=${VITE_BACKEND_URL}

The last line in the compose file allows us to use the variable defined in our root .env file and set the argument VITE_BACKEND_URL (used in the Dockerfile).

Now we're defining the value of VITE_BACKEND_URL in our .env file, passing it through docker-compose.yaml to frontend/Dockerfile and finally into the environment when Vite is building our app.

Then we can directly use process.env to load our variables.

import vue from '@vitejs/plugin-vue';

export default defineConfig(() => {
  return {
    plugins: [vue()],
    define: {
      VITE_BACKEND_URL: process.env.VITE_BACKEND_URL,
    }
  }
});

Putting it all together

Assuming the following project structure (displaying only relevant information):

app/
├─ backend/
│  ├─ Dockerfile
├─ frontend/
│  ├─ src/
│  ├─ Dockerfile
│  ├─ vite.config.js
├─ docker-compose.yaml

Now that we know how to avoid the pitfalls with environment variables in Vite during build time.

Let's define a Dockerfile for our frontend (assuming you've already initialized your frontend project):

# it's a good idea to pin this, but for demo purposes we'll leave it as is
FROM node:latest as builder

# automatically creates the dir and sets it as the current working dir
WORKDIR /usr/src/app
# this will allow us to run vite and other tools directly
ENV PATH /usr/src/node_modules/.bin:$PATH

# inject all environment vars we'll need
ARG VITE_BACKEND_URL
# expose the variable to the finished cotainer
ENV VITE_BACKEND_URL=$VITE_BACKEND_URL

COPY package.json ./

RUN npm install

# use a more specific COPY, as this will include files like `Dockerfile`, we don't really need inside our containers.
COPY . ./

FROM builder as dev
CMD ["npm", "run", "dev"]

FROM builder as prod-builder
RUN npm run build

# it's a good idea to pin this, but for demo purposes we'll leave it as is
FROM nginx:latest as prod

COPY --from=prod-builder /usr/src/app/dist /usr/share/nginx/html

CMD ["nginx", "-g", "daemon off;"]

What's happening here:

First of all we define 4 different containers: builder, dev, prod-builder and prod. We'll use them to switch between development and production.

The first container builder is tasked with installing the dependencies and preparing the environment variables.

We've already discussed the env variables in length. You can omit the ENV ... call if you don't need the variable in the finished product.

NOTE: The call to ENV will only propagate to derived container images. When we define an environment variable using the ARG ... ENV ... pattern, we'll only be able to use it in containers deriving from the one where these were defined. In our example the nginx container will not have access to the variables, and thats fine.

Next let's define our docker-compose.yaml

version: 3
services:
  frontend:
    build:
      context: frontend
      target: prod
      args:
        - VITE_BACKEND_URL=${VITE_BACKEND_URL}
    container_name: frontend
    depends_on:
        - backend
    networks:
      - api
  backend:
    build:
      context: backend
    networks:
      - api
networks:
  api:
    driver: bridge

Your env file in the root of the project

VITE_BACKEND_URL=https://backend.test

We've already defined the vite.config.js file in the previous sections.

If you want to change the target of the frontend build, you can either edit the main docker-compose.yaml or add a docker-compose.override.yaml file and do it from there.

Let's build:

docker-compose build frontend
docker-compose up -d frontend
docker exec -it frontend bash

Let's examine the environment using printenv:

root@a67cabd6fb54:/ printenv

HOSTNAME=a67cabd6fb54
PWD=/
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NGINX_VERSION=1.23.2
_=/usr/bin/printenv

So the VITE_BACKEND_URL is not in our environment as expected, we can console log it in one of our .vue files to confirm it was indeed compiled into our source files:

# App.vue

<script>
  console.log(import.meta.env);
</script>

Rebuild and rerun:

docker-compose build frontend
docker-compose up -d frontend

NOTE: You could run docker-compose up -d --build frontend, but that will actually build all services listed in the depends_on list in your docker-compose.yaml config file.

When we visit our homepage we'll see the console output in the dev tools.

Summary

We've learned how to inject environment variables during build time of our Vite frontend container. Since the dev container derives from the root builder, the environment variables will be still available when the CMD ["npm", "run", "dev"] line is run. We will NOT however have dynamic values, meaning changes to the .env file won't be reflected immediately. You can achieve this with the env_file option in the docker-compose.yaml configuration.
We also have to recognise that this is but a single way to solve a problem. I'm sure there are many other ways to solve this issue.

Python entry points

borisuu — Thu, 19 Oct 2023 07:52:45 +0000

Recently I became interested in using entry points to "invade" the namespace of a package. We'll define a base package which will allow different functionality through modules. We'll then expose the entry points and load any and all modules which adhere to our definitions.
We'll simulate a video/audio encoding tool. This should help make thing a bit more realistic. This will NOT be a tutorial on encoding/decoding, so if you're looking for something like that, this is the wrong article for you.

The base package

We need three modules in our base package: the main module which will expose the functionality to the users, a default module which will demonstrate the API and a plugins module which will expose a function to load plugins.
We'll call our base package "ender" (encoder + decoder), because it's fun and I'm also a fan of the books by Orson Scott Card. We'll create a plugin module "ender_mp3" which will use entry points to provide its functionality.
The file structure for the base package is as follows:

ender/
├── ender
│   ├── __init__.py
│   ├── empty.py
│   ├── main.py
│   └── plugins.py
├── poetry.lock
├── pyproject.toml
├── README.md

Now let's define the main part of our core package. We'll create a class to manage all modules and run them.

# in main.py
class Ender:
    def __init__(self):
        self.modules = []

    def work(self):
        for module in self.modules:
            module.work()

def main():
    e = Ender()
    e.work()
    return 0


if __name__ == '__main__':
    # behave like a nice CLI and return 0 when successful
    exit(main())

As you can see from the code above, the module is very simple. It initializes a list of modules and exposes a method work. When that method is called, all the registered modules will do their thing. We'll extend this later, but for now it's going to be enough to demonstrate how to register modules and use them.
You can run the main file, and you'll see nothing, because we haven't registered any modules.

poetry run python ender/main.py

Let's fix that and register a default empty encoder/decoder. First create the module where it will live:

# ender/empty.py
class EmptyEncoderDecoder:
    def work(self):
        print(f"'{type(self).__name__}'", "Default empty encoder/decoder working...")

    def register(self, core):
        core.modules.append(self)


def register(core):
    m = EmptyEncoderDecoder()
    m.register(core)

We've defined the empty encoder/decoder and we've included a register method, which we'll use to add our module to the core. We've also exposed a register function which will be called by our plugin loading logic. Let's go implement that:

# in ender/plugins.py
import importlib.metadata


def load_plugins():
    entry_points = importlib.metadata.entry_points()
    plugins = entry_points.select(group='ender.plugins')

    plugin_modules = []
    for plugin in plugins:
        plugin_modules.append(plugin.load())
    return plugin_modules

Let's break down what's going on in this file. We've declared a function load_plugins which can be imported by the core module and used to fetch all registered plugins. The line plugins = entry_points.select(group='ender.plugins') loads any module from any package which has an entry point named 'ender.plugins' defined either in a setup.py file or in the pyproject.toml. After that the module is actually loaded and then passed down to the list which is returned from the load_plugins function. Let's take a look at the entry point registration in pyproject.toml (managed by poetry):

# in the pyproject.toml of the base ender package
[tool.poetry.plugins."ender.plugins"]
"default" = "ender.empty"

Note: For other plugin management tools this section will look differently.

You can see we've registered a "default" module within the "ender.plugins" entry point, which points to the actual module 'ender.empty', which just maps to ender/empty.py. Now when the load_plugins function is run, the module will be loaded. Let's wire that up in our main.py:

# in ender/main.py
from ender.plugins import load_plugins

def main():
    e = Ender()
    # load and register plugin modules
    plugins = load_plugins()
    for plugin in plugins:
        plugin.register(e)

    e.work()
    return 0

If we run the code now, we'll get the output:

$ poetry run python ender/main.py
'EmptyEncoderDecoder' Default empty encoder/decoder working...

Take it one step further

Now we have made the local default encoder/decoder work, let's go and make a separate package. Create a plugin package using poetry:

poetry new ender_mp3

The file structure we get is:

ender_mp3/
├── ender_mp3
│   ├── __init__.py
├── pyproject.toml
├── README.md
└── tests
    └── __init__.py

Let's create our module in the ender_mp3 directory and add an mp3 encoder/decoder:

# in ender_mp3/ender_mp3/mp3_module.py
class Mp3EncoderDecoder:
    def register(self, core):
        core.modules.append(self)

    def work(self):
        print(f"'{type(self).__name__}'", "Encoding/Decoding MP3.")


def register(core):
    m = Mp3EncoderDecoder()
    m.register(core)

Then add an entry point to your pyproject.toml:

# in ender_mp3/pyproject.toml
[tool.poetry.plugins."ender.plugins"]
"mp3" = "ender_mp3.mp3_module"

The same as before, we've registered our plugin. Notice that we're not making use of the name we've given our plugin, here 'mp3', but it is indeed assigned to our EntryPoint. Depending on the use-case it might be needed or not.

Let's install it now and see it all come together. First go back to your ender directory and run:

poetry add ../ender_mp3

This is assuming you've put the two directories next to each other:

.
├── ender
│   ├── ender
│   │   ├── __init__.py
│   │   ├── empty.py
│   │   ├── main.py
│   │   └── plugins.py
│   ├── poetry.lock
│   ├── pyproject.toml
│   ├── README.md
└── ender_mp3
    ├── ender_mp3
    │   ├── __init__.py
    │   └── mp3_module.py
    ├── pyproject.toml
    ├── README.md

Now when you run your main package, you'll get more output:

$ poetry run python ender/main.py
'EmptyEncoderDecoder' Default empty encoder/decoder working...
'Mp3EncoderDecoder' Encoding/Decoding MP3.

Beyond the basics

There are of course packages which have dealt with all the tricky parts of this workflow. We'll take a look at 'pluggy' which takes this concept to another level.

Let's rewrite our core package and then we'll go on to rewriting the plugin.

Install pluggy

poetry add pluggy

First create a spec file for specific hooks:

# in ender/hookspec.py
import pluggy

hookspec = pluggy.HookspecMarker('ender.plugins')


@hookspec
def ender_plugins_load_module():
    pass

Now let's make our default implementation use the pluggy specs:

# in ender/empty.py
from ender.hookimpl import hookimpl


class DefaultModule:
    def work(self):
        print(f"'{type(self).__name__}'", "Default empty module")

    def register(self, core):
        core.modules.append(self)


@hookimpl
def ender_plugins_load_module():
    return DefaultModule()

So we've replaced our register function with a hook implementation annotated function which just returns the module.

Now let's go ahead and modify our main.py:

# in ender/main.py
import pluggy
from ender import hookspec, default_module


class Ender:
    def __init__(self):
        self.modules = []

    def work(self):
        for module in self.modules:
            module.work()


def main():
    ender = Ender()
    pm = get_plugin_manager()
    modules = pm.hook.ender_plugins_load_module()
    for module in modules:
        module.register(ender)

    ender.work()
    return 0


def get_plugin_manager():
    pm = pluggy.PluginManager("ender.plugins")
    pm.add_hookspecs(hookspec)
    pm.load_setuptools_entrypoints("ender.plugins")
    return pm


if __name__ == '__main__':
    exit(main())

We've now introduced a get_plugin_manager function, which will create a plugin manager object for the "ender.plugins" entry point. We'll tell it about our hook specification and then we'll load the entry point.

In our main we'll again initialize Ender and then we'll get the objects we receive from the ender_plugins_load_module hook, loop as before and register them with the ender instance.

Note that we haven't done a lot of work, just changed a couple of lines in some files. The pyproject.toml definition stays the same.

Let's go and prepare our plugin:

from ender.hookimpl import hookimpl


class Mp3EncoderDecoder:
    def register(self, core):
        core.modules.append(self)

    def work(self):
        print(f"'{type(self).__name__}'", "Encoding MP3")


@hookimpl
def ender_plugins_load_module():
    return Mp3EncoderDecoder()

Now we're doing something a bit weird here. We're importing the hookimpl from the core package, although we haven't installed it. You'll probably get some errors because of this in your IDE, but just ignore them. This will work just fine.

Now replace the register function with the annotated implementation and you're done. Install the plugin:

# let's just remove the old package from our virtualenv
# from the ender/ project directory
poetry remove ender_mp3
poetry add ../ender_mp3

Now when you run your project you'll see the same message as before. Voila, we've moved our crude plugin implementation to this magnificent much more advanced version. The awesome part is that now we're able to define multiple hooks for our core package, use attributes when running the hooked functions and generally achieve much more, with not a lot of extra work.

Let's go even further

Ok so now we're actually able to move some logic around, because pluggy is just that powerful. We can now easily split the encoders and the decoders and load them separately into different objects.

For that we'll rename our spec to load_encoders and add another one called load_decoders.

# in ender/hookspec.py
import pluggy

hookspec = pluggy.HookspecMarker('ender.plugins')


@hookspec
def ender_plugins_load_encoders():
    pass


@hookspec
def ender_plugins_load_decoders():
    pass

Note that the hook specifications MUST be named after the marker. In our case the marker is ender.plugins which would translate to ender_plugins. This is important and the whole setup won't work if you don't follow this convention.

Let's quickly update our mp3 encoder/decoder and make sure it will work.

# in ender_mp3/mp3_module.py
from ender.hookimpl import hookimpl


class Mp3Encoder:
    def work(self):
        print("mp3 encoder working...")


class Mp3Decoder:
    def work(self):
        print("mp3 decoder working...")


@hookimpl
def ender_plugins_load_encoders():
    return Mp3Encoder()


@hookimpl
def ender_plugins_load_decoders():
    return Mp3Decoder()

As you can see we've split our single module into two separate classes, each responsible for it's own task, e.g. encoding or decoding.

Let's update the default empty module as well:

# in ender/empty.py
from ender.hookimpl import hookimpl


class DefaultEncoder:
    def work(self):
        print("Default encoder working")


class DefaultDecoder:
    def work(self):
        print("Default decoder working")


@hookimpl
def ender_plugins_load_encoders():
    return DefaultEncoder()


@hookimpl
def ender_plugins_load_decoders():
    return DefaultDecoder()

And finally let's update the main package:

# in ender/main.py
import pluggy
from ender import hookspec, default_module


class Ender:
    def __init__(self, hook):
        self.hook = hook
        self.encoders = []
        self.decoders = []
        encoders = self.hook.ender_plugins_load_encoders()
        for encoder in encoders:
            self.encoders.append(encoder)

        decoders = self.hook.ender_plugins_load_decoders()
        for decoder in decoders:
            self.decoders.append(decoder)

    def work(self):
        for enc in self.encoders:
            enc.work()

        for dec in self.decoders:
            dec.work()


def main():
    pm = get_plugin_manager()
    ender = Ender(pm.hook)
    ender.work()
    return 0


def get_plugin_manager():
    pm = pluggy.PluginManager("ender.plugins")
    pm.add_hookspecs(hookspec)
    pm.load_setuptools_entrypoints("ender.plugins")
    return pm


if __name__ == '__main__':
    exit(main())

Let's start near the bottom. We've kept the get_plugin_manager function intact and we load it before we initialize the Ender class. We'll just add a hook argument and pass it to the instance.

In the __init__ method we accept the hook and use it to load the encoders and decoders and save them to their respective property for later use.

We'll also update our work logic to use the encoders and decoders and we're done. Just reinstall the plugin and take a look:

poetry remove ender_mp3
poetry add ../ender_mp3

Run the application

$ poetry run python ender/main.py
mp3 encoder working...
Default encoder working
mp3 decoder working...
Default decoder working

You've probably noticed that the order of the modules is now switched. This is because the modules are loaded in LIFO order. If you want to restore the order you can just sort the encoders and decoders after loading them.

Further thoughts

We've seen how to go from the simple idea of loading plugins through the awesome entry points feature, and we explored how to scale up to use something like pluggy to achieve more complex setups. With all that in place we'd be capable of performing a more complex setup when we load the encoders and decoders. We should expand our main application to allow the user to select if they want to encode or decode, add some basic implementations for certain audio and video types, overwrite them when loading plugins, or at least give the user the opportunity to do so. These are just some ideas. Feel free to experiment on this basis.