There are several tutorials and files for running wordpress in docker. For me nearly none of them worked, therefore i wrote my own rerunable docker-compose file, which I like to share here now:
Just put this code into docker-compose.yml, change the passwords accordingly and run a new wordpress simply by:
For my audiobook-feeds github repository I needed docker to be able to use a host volume mount which contained a remote sshfs mount located on my local raspberry pi with a attached external hard drive. For my own sake of documentation and to offer you something to profit from, I created this small howto:
First of all, connect to your server and mount your remote device via sshfs using the -o allow_root flag. The allow_other option I tried first didn’t work for some reason.
sudo sshfs firstname.lastname@example.org:/my/remote/path/ /my/local/server/path/files/ -o allow_root,reconnect,default_permissions
Then run the container using the –privileged flag.
sudo docker run --privileged --rm -v `pwd`:/usr/src/myapp -w /usr/src/myapp -it --rm -p 127.0.0.1:8088:8080 --name audiobook-feeds audiobook-feeds go run feed.go
After that the root user of the container is able to list and to server the remote files.
I love podcasts.
I use them frequently and automatically downloaded by the Podcatcher BeyondPod onto my smartphone. In contrast to podcasts, I transfered my audiobooks to my smartphone by cable – which usually was very annoying. Therefore I wrote a little script that is able to close the gap by converting all my audiobooks into subscribable podcast feeds!
Of course it is open source and can be found here: https://github.com/PaulPetring/audiobook-feeds
Some adittional facts:
- it serves a website to browse your audiobooks and subscribe to certain books
- serves rss and atom feeds for import
- it offers a simple password protection to prevent copy right issues
- runs in docker container (see MakeFile and DockerFile)
- works when placed in subdirs example.com/audio/ (e.g. reg for ssl without wildcard)
- allows custom theming and uses material design as default theme
- handles encoding of filenames at best effort
Screenshot of the first available version of my audiobook-feeds project
I use it on regular basis and would like others to enjoy it as much as I do. So please feel free to use, spread and contribute to it. And see you soon 🙂
In the recent days I moved this blog to a new server mainly to fix the latest SSL issues like POODLE- , Heartbleed – and SSL downgrade attacks. In order to save money I used the free of charge startSSL.com-signed certificate, which offers to sign in private generated certificate sign requests for your main site and one sub domain. This does not just keep the little padlock next to the address pane green but furthermore allows a higher rank in google searches in future.
But moving a blog from a physical server usually means a lot of programming pain: files have to be moved, databases exported and imported back again, configuration files need to be adjusted and so on. To avoid this unnecessary work in future I was researching some possible solutions. First of all, its nothing new at all – visualization and containerization are multiple years old technologies. The most remarkable approach in my optionion is docker. Its more lightweight than VMWare or VirtualBox, while supporting most of the features they offer. With its help you can run multiple instances of linux machines on a (single) physical host. Besides that is a real security feature as it keeps every process inside its on container never allowing to affect the functionality of the others even during security breaches.
Its also possible to version a dockerized application and share them over github. In case of wordpress there are multiple versions available: docker-wordpress by jbfink, docker-wordpress-nginx by eugeneware, both of them lack of dockers VOLUME support, but after adding this, they still saved a lot of work.
In conclusion this blog is now in its own container, using its own http nginx, mysql and php instances. The container in turn is made public by a ssl reverse proxy nginx, which in case its required can be supplied by varnish caching in future.