Skip to main content

Run SweetHome3D Without Install

About

SweetHome3D is a free interior design application. You can install it from most repos; however, the install often requires a lot of unneeded libraries and/or didn't work well for my situation. There are several articles that suggest you can/should run it directly but none gave the steps needed so I thought I would pull together a quick post on it.

It's not difficult or glorious, hopefully the info will be of use to others. Here are the steps:

  1. download SweetHome3D
  2. extract files: tar -xzf SweetHome3D-*.tgz
  3. run the jar: ./SweetHome
  4. note: you will need a JRE - openjdk works just fine

Lesson's Learned

I did manage to produce a working docker sweethome3d which keeps you from installing anything (other than docker); however, the java GUI blacks out sections of the app from time to time and wasn't worth the effort given I already have java installed for dbeaver. If you are interested in getting it to run in docker feel free to start with what I produced: https://gitlab.com/drad/docker-sweethome3d.

boi Tutorial

This tutorial will show how to take an existing application (the dradux.com website itself) and deploy it to a kubernetes cluster using boi, a lightweight tool for building and pushing docker images. Deploying an application to k8s can be a daunting task depending on the complexity of your application and the needs therein; however, as this post shows, it can be quick (~30 minutes) and relatively easy if you have the needed components in place.

Key Components

  • an application (ready to go)
  • a k8s cluster
  • an image repository

The Application

For this tutorial I am using the dradux.com website itself as an example. Its source is on gitlab. The app is a nikola based static site. To 'generate' the site you would simply run nikola build, the built site is located in the output/ directory. This part was easy as it already existed!

The k8s Cluster

Easy, I already had one. If you don't, I suggest looking at Rancher as you can get a k8s cluster set up in minutes.

The Image Repository

I have spent countless hours setting up internal registries, registries inside of k8s, and integrating with external/public registries. If your app is close-sourced this task will take more time and be more difficult. As of late I have started using the registry which comes with a gitlab project as it is free and I do not need to manage the registry. If you want to see one, check our the dradux-site registry.

Dockerizing Your App (if needed)

This is an art in itself and can take on a life of its own. I suggest a little planning before doing this and keep things simple. Your application/code should do the heavy work and docker should be a light wrapper to bundle it all up but some things (old java apps) just wont stay light in my experience. If you need help in dockerizing feel free to contact us!

Dockerizing dradux-site was simple as the site is a static site - just html/javascript/css. No server-side scripting, database, etc. All we need is an --nginx-- lighttpd instance, add the app code and we are ready to go!

Feel free to take a look at the Dockerfile along with its entrypoint.sh (used to run rsyslogd which sends my web logs into a graylog server) and the lighttpd.conf.

That's all it took to dockerize the app!

Add boi Integration

As mentioned before boi is lightweight. To add boi to the project I created the .boi.toml configuration file. That is pretty much it, now you can build your image and push to your image registry.

Build & Push Your First Image

Use boi to build and push an image of the application: boi build --version=1.0.0. If all goes well you will have version 1.0.0 of your application in the container registry specified.

Deploy to k8s

Before you can deploy to k8s you need to setup your deployment. This can be done in several different ways in k8s, we will use a standard namespaced deployment as an example.

First, create your namespace and then create the deployment:

apiVersion: v1
kind: List
items:
- apiVersion: apps/v1beta1
  kind: Deployment
  metadata:
    name: dradux-site
    namespace: dradux-site
  spec:
    template:
      metadata:
        labels:
          run: dradux-site
      spec:
        containers:
          - name: dradux-site
            image: registry.gitlab.com/drad/dradux-site:latest
            resources:
              limits:
                memory: 128Mi
                cpu: 100m
            ports:
              - containerPort: 80
- apiVersion: v1
  kind: Service
  metadata:
    name: dradux-site
    namespace: dradux-site
    labels:
      run: dradux-site
  spec:
    ports:
    - port: 80
    selector:
      run: dradux-site

Notice that the image for the container is set to where we push to with boi - also note we are pulling the 'latest' tag and in boi we have it set to apply the 'latest' tag on build.

Next, create an ingress to route traffic into the service:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: default
  namespace: dradux-site
spec:
  rules:
  - host: dradux.com
    http:
      paths:
      - path: /
        backend:
          serviceName: dradux-site
          servicePort: 80

A standard ingress, we will SSL terminate at a LoadBalancer in front of k8s.

Summary

You should now have the service up and an ingress to catch the traffic inside of k8s. You still have the task of managing the DNS to route dradux.com to the k8s cluster (and SSL termination at a LB if needed) but other than that you should be able to hit your URL and see your site!

This uses the bar variable: bla

Web Server SSL Certificate Layouts

HAProxy

All of the following in one .pem file:

  1. The Certificate for your domain
  2. The intermediates in ascending order to the Root CA
  3. A Root CA, if any (usually none)
  4. Private Key

Nginx

Two separate files:

  1. The Certificate for your domain, the intermediates, and root CA are in one file
  2. The private key

Audio Player Comparison

Requirements

  • must be light on cpu and ram
  • small overall footprint
  • perform basic audio playing features (playlist management a plus)

Findings

App Type Size CPU RAM Notes
cmus ncurses 192,506 3.7% 8.096 really like it, mutt of audio players
deadbeef GUI 2,321,554 5.0% 22,496 basic ui; it loads/plays my playlist!
vlc GUI 1,211,816 10.3% 45,984 A great 'plays anything' player but heavy on runtime resources
banshee GUI 192,506 uses mono..., UTTER CRAP! will not play any of my music, GStreamer library error: Shutdown; do not like the interface (discover based)
rhythmbox GUI 446,246 does not work Jack error, do not like the interface (discover based)
musique GUI 574,458 9.3% 53,992 wants to scan for music...; very nice looking but doesn't seem to be able to save/load playlists, perhaps need a newer version
minirok GUI 74,524 6.7% 81,052 basic, doesn't seem to have a save/open playlists, does 'reload' last playlist, pulls in a LOT extra files (260+mb)
amarok GUI 5,944,266 21.9% 122,224 pulls in 226mb additional; way to much cruft
lxmusic GUI 93,624 basic, seems nice but it will not open any of my music, no errors/notices at all
juk GUI 660,696 10.3% 55,992 adds 163M of additional pkgs; I like the player, nice, simple, asks for search folder, and auto-imported playlist
guayadeque GUI 1,632,512 10.3% 43,636 nice l&f; imports playlists; a bit odd to get around in; has way to many features I'll never use (jamendo, etc.)
aqualung GUI 800,842 5.7% 21,796 mdi interface (bit oldschool looking; loads my playlist!;I like it!
bluemindo GUI 168,876 odd interface, difficult to find/do anything, would not play my music
exaile GUI 1,056,136 12.0% 59,220 not bad on install; somewhat intuitave; opens/plays my playlist!
moc ncurses 311,552 4.0% 9,260 I like!; plays my playlist!; simple and straightforward!; very nice, maybe easier to use than cmus
yatm CLI 14,258 too basic, just a cli player like aplay; no playlist support
yauap CLI 21,266 simple cli player; no playlist support
qmmp GUI 95,514 8.3% 35,156 odd but basic/nice UI; opens/plays my playlist!
  • cpu % after 1min of play of 5 songs
  • ram (RES) XX after 1min of play of 5 songs
  • to find app size (in K): apt-cache show cmus | grep Size:

Test

  • install app
  • open app
  • create playlist with 5 songs
  • If it aint one thing, paramore-misery business, Hit it Again, Foo Fighters - Best of You, Foofighters everlong
  • close app
  • open app (with timer), open playlist, and play: appname & top -d 3.0 -n 21 -p $(pgrep -d',' -f appname) && fg
  • open app
  • get CPU/Memory stats from top
Results

cmus and moc are both good, need to run a larger (more songs and longer run) sample for memory/cpu comparisons.

Test #2

  • playlist has 37 songs (Advent Chamber Orchestra & Various Artists (Dawn of)
  • play for 45m
  • measure results
App Type Size CPU RAM Notes
cmus ncurses 192,506 3.0% 8,112
moc ncurses 311,552 3.0% 10756 I noticed that often cpu utilization for moc was 0% during the run
Notes
  • cmus is a bit technical to learn but I do like it
  • moc/p is a bit more simple/straightforward
  • moc/p has a sort of front and back-end, you can close the ncurses ui and the backend (also mocp) will continue running, the above measurement for moc is with the front-end closed

Using cmus

  • man page
  • arch wiki
  • :a: ~/music - add files
  • v: stop play
  • c: pause play
  • b: next play
  • x: play
  • :clear - clear current view
  • y - add to playlist
  • 1 - library
  • 2 - sorted library
  • 3 - playlist
  • 4 - play queue
  • 5 - browser
  • 6 - filters
  • 7 - settings
  • :save -p FILE - saves playlist view to playlist file
  • :load -p FILE - load a playlist file to playlist view
  • s - toggle shuffle
  • r - toggle repeat
  • C - toggle continue

Using moc

  • install moc and moc-ffmpeg-plugin
  • start with mocp