After reviewing open-source options for static website content creation, I rediscovered jekyll, a static web content management platform supported by a strong community with a good variety of available site templates and extensions.
Here’s a quick set of instructions on how to set-up and publish a static website, leveraging the official docker jekyll container and amazon s3 to host.
First you’ll want docker installed and then select a template from the substantial catalogue available.
docker pull jekyll/jekyll
download and unzip your theme & cd into it then…
docker run --rm --label=jekyll --volume=$(pwd):/srv/jekyll -it -p 127.0.0.1:4000:4000 jekyll/jekyll jekyll serve --incremental
Open your browser and navigate to localhost:4000 to view the demo pages
Modify _config.yml and anything else you wish to, jekyll will detect the change and regenerate the pages, refresh your browser (ctrl/command shift +r) and view the change
If you’re happy with the changes you can ctrl C to kill the jekyll docker process and publish the pages to git, and or amazon s3.
aws s3 sync _site s3://mybucket.redgrid.net --region=ap-southeast-2
The important part other than a bucket policy is a cname from the intended DNS record mybucket.redgrid.net to mybucket.redgrid.net.s3-website-ap-southeast-2.amazonaws.com
Spare moments have been too few of late.
Where fortune has smiled, I’ve tinkered with a proof of concept multi-node Havana release openstack cloud.
A tasty mix of instant success and unrelenting obstacles.
The magnitude and momentum of the OpenStack project is staggering.
I kicked off the POC project just days before the Havana release; after much reading, researching, testing and destroying, he we are a matter of weeks away from Icehouse.
With the added featrues of Trove and Ironic, and a personal history of working with SQL and bare metal deployments, the temptation to wipe clean and start again is too great to resist.
A call for Openstack to adopt the AWS API as the native API was made a little earlier this week.
In order to position Openstack as the dominant option for hybrid private/public cloud solutions, it’s argued that alignment with the public cloud dominance of Amazon Web Services & Google Compute Engine is an imperative.
While the point is made that alignment with the dominant cloud service providers is important, and the development cost of maintaining separate sets of API’s is in ways inefficient; the ability to fast track feature development could be impacted by sacrificing total control over the API. Similarly, Openstack’s ability to take advantage of new AWS features could be compromised through the dispersal of development resources.
Read the Open Letter here
Integration of the Ceph clustered object storage system with Openstack appears to growing more popular.
Ceph claims to deliver better performance for large block images than a single server. Combining performance with “unlimited” scalability, high availability and load balancing, it’s well worth a look.
Network World details insights into the Netflix cloud infrastructure.
Why Netflix is one of the most important cloud computing companies
On the topic of Netfilx, despite contributions to open source cloud technologies, there remains no client to utilise their cloud based video streaming service on the Linux platform.
I recently read of a new HTML5 based browser interface for the IE 11 and Windows 8.1 relase; potentially indicating a move away from the proprietary solutions such as Microsoft silverlight.
A long way from client access on the Linux platform, but perhaps edging slightly closer.
The RDO openstack quickstart guide recommends using nova network over Neutron/Quantum.
With Neutron/Quantum clearly the way of the future, I’m willing to suffer a little pain to take the road less traveled.
The hardest part to getting floating IP’s on Grizzly with Quantum, was finding the information.
The Debian openstack guide proved the best resource.
While there is a lot to be said for the knowledge gained from a step by step manual installation of openstack, it’s not a journey for the faint of heart.
Bugs, outdated guides and errors have been par for course; inordinate time can be lost in futile pursuits with little long term gain other than preservation of the IT ego.
Enter RDO – a puppet based automated installation that reduces the time required for installing openstack, from best part of a day to ~ 15 minutes.
Despite for many years now preferring Debian based systems, I felt quite at ease with the simplicity of the RDO installation on Red Hat 6.4.