History This humble blog previously was based on an Amazon EC2 instance running Debian 8 as operating system. For creating and serving the blog posts, several incarnations of the Ghost blogging software fronted by the NGINX web server were used. At the time of releasing this article, this site is served by an Amazon S3 bucket holding a statically generated version of this site. See below for technical details.
I was going to start this article with the question: do you still remember Microsoft Access? But then I found out that this boil of a “database” system still exists. In my former life as a developer, this pseudo database product caused me so much pain because it was constantly abused for uses not really feasible for this kind of product. MS Access is a perfect product for Windows users managing their catalog of movies or contacts, collections of whatever kind or, to say it in a simpler way: for local personal usage of low volume data.
I recently discovered a problem when creating a provisioning script for Ghost with Ansible 22.214.171.124 on Debian 8 Jessie. The problem happened after providing the init script for Ghost and starting the service. The shell code would look like this: sudo update-rc.d ghost defaults sudo update-rc.d ghost enable sudo service ghost start The representation of the above in Ansible: - name: install - enable Ghost service service: name: ghost enabled: yes state: started become: yes On my Debian 8 based Vagrant testing instance starting the Ghost service always failed - starting the service only worked after restarting the Debian system.
The need for monitoring Many software projects are constructed out of many components which sometimes can be hard to monitor. Especially during the development phase of an application, it can be crucial to gain information about possible bottle necks that may prevent successful production usage of your project very early. One possible performance metric may be the amount of possibly unnecessary SQL statements executed while using your application - this is a real use case I had in a large Magnolia project to increase performance.
In this article I’ll show you how to configure your development project with a Magnolia author and a public instance using a MySQL database over JNDI. This tutorial can easily be used to also with other databases like PostgreSQL by slightly adjusting the configuration shown below. Using JNDI has the advantage that this data source is known to the Tomcat container and can be automatically monitored by tools like JavaMelody.
In my last post I showed you how to setup a basic execution environment based on Maven and Cargo with a Tomcat 8.x application server; I recommend to read that post if you need an introduction. This article will extend the previous configuration in a way that you can run your web application with a self-signed certificate using the HTTPS protocol in a development / test environment - production of course needs a “real” certificate.