Install Tryton using Docker on Ubuntu

In this tutorial I will install get Tryton using Docker, the fastest way to host Tryton for evaluation. The Tryton project provides a Docker container for use on Ubuntu Linux, which I will host a virtual machine on a FreeBSD host.

Create Virtual Machine

Install Ubuntu 20.04 using the Ubuntu distribution DVD ISO and using the startup wizard configure appropriately.

Copy your user ssh key to the new server and disable password login.

Configure vm port forwarding. Port forwarding with VirtualBox must be done with the vm powered off.

Name: ssh
Protocol: TCP
Host Port: 8000
Guest Port: 8000

Update Server OS

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade

Install Docker

$ sudo apt install docker.io

Install Tryton

$ sudo docker pull tryton/tryton

Start a PostgreSQL instance

The Tryton image will be pulled from library/postgres

$ sudo docker run --name tryton-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_DB=tryton -d postgres

Setup the database

$ sudo docker run --link tryton-postgres:postgres -e DB_PASSWORD=mysecretpassword -it tryton/tryton trytond-admin -d tryton --all

The script will prompt for:

“admin” email for “tryton”
“admin” password for “tryton”

Store the password in a key vault for safe future reference.

Start Tryton Instance

$ sudo docker run --name tryton -p 8000:8000 --link tryton-postgres:postgres -e DB_PASSWORD=mysecretpassword -d tryton/tryton

Start Tryton cron Instance

$ sudo docker run --name tryton-cron --link tryton-postgres:postgres -e DB_PASSWORD=mysecretpassword -d tryton/tryton trytond-cron -d tryton

Create bash Startup Script

Without further configuration the Docker container will not start automatically when the server starts. While it is possible to configure Tryton to automatically start, I have created a simple bash script for convenience to start Tryton manually.

dale@starlord:~$ cat start-tryton.sh
#!/bin/bash
# run using sudo
docker start tryton-postgres tryton tryton-cron
dale@starlord:~$

References

Install: https://hub.docker.com/r/tryton/tryton/
Setup: https://nextcloud.rollentausch.eu/index.php/s/SKZfnCFP4YKYZJE

January 28, 2021February 3, 2022

The Startup’s Guide to Product Development

Matis Drusts has been kind enough to create and share a comprehensive overview for embedded hardware product development. It should be recommended reading for all the idea people who just want to “git’r done”. 😉

Click here to open the image, then click image to zoom.

Thanks also to John Teel for first sharing the infographic on his Predictable Designs blog.

November 25, 2020February 3, 2022

Performance Monitoring using htop

htop is a great tool for viewing the basics of what a server is doing, in particular the real-time CPU and memory graphics. However, the colors in the bar graphs can make it difficult to distinguish between CPU tasks being executed (low-priority, normal, kernel and virtualiz), and the type of memory in use (used, buffers and cache).

In this case, the “no-color” option can be used which causes the bar graphs to use characters instead of colors for sub-categories.

% htop -C

November 24, 2020February 3, 2022

Using htop to explore server performance

I recently replaced the server for dalescott.net after a drive failure using a faster system, but my initial perception was that it was slower!

The “new” server is a Intel Core2 CPU 6600 2.40GHz with 6GB of RAM. In addition to the services running on bare metal, VirtualBox is used to host ERPNext using one core and 2GB RAM. It was the ERPNext response that seemed particularly slow. Investigating, I found a combination reasons as is typical of most problems.

First, I examined the apache logs and found the server was the target of a penetration attack around the time I had noticed response was “slow”. The server regularly shows 1000+ penetration attempts in a 24hr period, which tend to occur in clusters. However they have been more an annoyance than a significant concern, as I had not noticed them having a significant effect on server performance. Next, I examined virtual machine performance and found CPU use was 100% when ERPNext was being accessed.

While not finding a definitive cause, it seems likely the additional CPU load from the penetration attack was starving the already high CPU requirements of ERPNext. While clearly ERPNext is processor-constrained, under normal load the server can still provide adequate performance for basic presentations or training with a limited number of concurrent users. However, not if someone is knocking on the front door trying to break in at the same time.

dalescott.net SaaS Architecture

Load At Rest

Below is the virtual machine and host server when at rest (no logged-in ERPNext users, and no on-going brute-force ssh or web app login attempts). The vm load (top) is 3% and the host (bottom) server cores are 5% and 2% (the 2% core is the erpnext server).

Load When Stressed

Below is the server when an ERPNext user logs in and accesses an Item list. The vm load (top) has maxed out at 100% and is using half its available memory. On the host (bottom), core #2 is almost 70% (erpnext), but core #1 is only 35% and only half the total available memory is being used, which is good.