Earlier this week I had a silly idea and wanted to throw up a static website w/ some very basic content (much like GitHub Pages provides). I of course wanted to host this myself, not on GitHub.

After a quick search I found this is actually very easy to do if you're using dokku (which if you've been following along w/ me on this indieweb journey you may already be!)

Install buildpack-nginx

$ cd /var/lib/dokku/plugins
$ git clone https://github.com/rhy-jot/buildpack-nginx
$ dokku plugins-install

That's it! Now you can make a static site. Make a new repo with a .nginx file (it can be empty, it just has to exist) and a www folder. Everything in the www folder will be served at the root of whatever domain you point it to with dokku

Make your site

$ touch .nginx
$ mkdir www/
$ echo "<h1>Hi!</h1>" >> www/index.html
$ git add remote dokku dokku@dokku-server:hostname
$ git add .
$ git commit -m "Hello World"
$ git push dokku master

You can now to go hostname and see your html! It's that easy. To reiterate: anything you put in the www folder will be served at the configured site.

P.S. the idea that made me look into this was this one

Update Sept 2014

I am no longer using gitlab, it stopped working and I didn't have the energy to fix it. Details here.

Original article

As I've talked about before, I'm currently trying to put some of the principles of indieweb into practice. I started by hosting my own blog content, and then threw up a quick [pastebin clone][artifice] to host my own pastebin data. I decided that next up on my list of things to try to homestead would be my code.

I use git for my version control, and currently host all of my repos on github. Indieweb journey notwithstanding, I have many reasons lately to reconsider that.

Of course, with github you still can own your data, git is a decentralized version control system so you have a complete copy of everything even on your local clone. The things github provides (that are also the data you do not control) are things like issues. Things that are the real 'community' part of your project. As my friend @baldwin said to me earlier today, "It's interesting that github seems to have re-centralized git."

I actually don't know how easy gitlab makes it to do these things. If you have a relatively small project, and thus community, it's a lot to ask a person to create an account on your own little private gitlab instance just to contribute. As I write this I have no idea if it's easy to submit issues or merge requests from outside your local gitlab ecosystem. In theory it should be possible since git is decentralized to send merge requests between systems. Identity could also be handled by oauth (or even better persona) so that participating in someone's project doesn't require a dedicated account in their ecosystem. I'm hoping that these things are either already easy to do, if not they appear to be crucial to making the community portion of version control as open as git itself is.

Installation

I knew that I wanted to be able to use docker to run gitlab. I was already using it if you'll recall from my previous posts. Fortunately there is a gitlab-endorsed docker config. Unfortunately it doesn't work out of the box (the firstrun.sh file tries to build assets before mysql is running) and parts are super confusing (ssh port forwarding for instance is completely hand-wavy). It is also out of date and uses mysql. So like the bad-decision-making person I am, I forked it to get it on the latest versions of things, use postgresql, and most importantly actually work. You are welcome to try your luck w/ the original. Examples here will be using my fork.

The first step is to tell docker about the image:

$ cd /var/local
$ git clone https://github.com/wraithgar/gitlab-docker.git gitlab
$ cd gitlab
$ docker build -t gitlab .

This part takes awhile so maybe go read a book while you wait. Might I suggest Something Greater than Artifice? It may help you decide after all that silos are real.

Configuration

Now it's time to go into your newly cloned gitlab-docker repo and change the settings. in config/gitlab.yml just change the host: config under gitlab: to whatever hostname you are going to want to run gitlab on (I used code.danger.computer). pick a port you want to use on your host machine for git ssh, 222 is a common alternative. Uncomment and set the ssh_port under Advanced settings to this number. Unfortunately this is not something you can configure in docker so you'll have to pick a port number, set it in the config file, and remember that port number later when you forward it to this image. in config/nginx.conf change YOUR_SERVER_FQDN to the same hostname as you put in config/gitlab.yml in config/nginx.conf change PATH_TO_GITLAB_DOCKER to whatever folder you cloned the gitlab-docker repo into (heads up it's in there several times, change them all)

There are a lot of things to configure in config/gitlab.yml not the least of which could be omniauth settings. These settings are not trivial if you are unfamiliar w/ rails and gems. That kind of thing feels like a "future" post instead of trying to work it into this one. If you are feeling adventurous try this post. I hope to revisit this file in a separate post.

I won't be adding omniauth to my initial run of this image because I think config items like that should be changeable after the fact, so I want to try changing them and seeing where the pain points are.

Moving on, the next config item is setting passwords for the gitlab user. Set that in firstrun.sh (and of course pick a good password, c'mon now).

Running

In dockerland, running an image is referred to as 'making a container'. This is when your code starts to run and is where you enter the last bit of configuration items (which other than environment variables sadly all appear to be CLI only).

If you've set everything up right, you should be able to run your image in a new container. However there's one more thing missing from the instructions for gitlab-docker. Remember the port number you configured in config/gitlab.yml that I said to remember? You're going to need to tell docker to forward that from the host machine to the container. In this example I've used port 222. Note that -name is depricated and my example uses --name (the cd into your gitlab-docker folder in the instructions also appears to be superfluous)

$ docker run -d -v /var/local/gitlab:/srv/gitlab:rw -p 222:22 gitlab

Wrapping up

All that's left is for you to let nginx know how to serve gitlab. Copy your edited config/nginx.conf file to /etc/nginx/conf.d/gitlab.conf and restart nginx. If everything worked well (fingers crossed) you should be able to go to the hostname you set up and log in as the predefined user admin@local.host with password 5iveL!fe. You'll be prompted to change that password of course.

You can check out the fruit of my labor at code.danger.computer

The Future

Up next I will actually have to run gitlab and try to get my code into it, including using git over ssh. After that, it's likely making auth happen in a distributed way, and other configuration tweaks.

A small nitpick is that gitlab prompts for login by default rather than redirecting to /public. I will see if that can be changed.

Also I know you can publish docker images but I just didn't have the energy to figure that out after finally getting things working. If I get that working I'll update the readme and this post.

Finally, there is a docker file for the gitlab-ci service. The ci portion of gitlab looks like it will be very useful and I can't wait to dive into that eventually.

After this experience it is apparent that neither gitlab nor docker is really ready for primetime. You can get it to work, eventually but it took me the hobby time of a better part of a week to get things even running for the first time. Hopefully my efforts can be built upon now, with the end goal being even more people being able to host their own code.

A note about swapfiles

In some of the documentation for gitlab I was reading, it was mentioned that if you don't have a lot of memory on your system (say, for instance you went with the small 512MB of ram for your droplet) you may have problems running gitlab, especially the first time. Following the basics in this howto I added a 512MB swapfile to my droplet. The only difference between that howto and what I did was that I set count=512k instead of count=256k in the dd command that created the swapfile. Your environment may not need this but if you're copying what I am doing then it's good to know that I took this step locally.

Update:

After only a few days of running my droplet ran out of memory and I couldn't even publish to this blog w/o dokku crashing. I would definitely go for a slice w/ at least 1GB. I will be upgrading my own shortly.

One of the places it's very very easy to own your own data is in the realm of pastebin. Even though the data you share via these services is public, you still are throwing it onto someone else's silo to host. You don't control how long they'll keep it.

Thankfully there is a super easy pastebin server called hastebin. It is dokku-ready (I forked, pushed, and had it instantly working). In my opinion though, it was not exactly what I wanted out of the box. For one, there was an outstanding pull request to add os-x hotkeys that I would have like to seen merged in. The other piece missing is any sort of authentication. It's one thing to provide pastebin services for yourself, it's another thing to just have an open pastebin service running where anyone can dump unlimited data onto your server.

What I ended up doing was forking hastebin, merging the os-x hotkey pull request, and writing a simple auth plugin schema. With the auth schema I added you can decide if you want to lock down reads or writes. I chose to lock down writes only, so that you would need a valid login to post new content, but any content posted could be read by anyone w/ the link. Perfect for my setup, only I can add content, but I can share it with anyone, and the data is still mine.

If you want to check out my fork you can find it here, and you can see an example of one of my pastebins here.

Update: Sept 2014

The experiment is over, and this dokku setup was too fragile to succeed. Links have been updated where possible to point to the code that remains (I'm still using bumble).

Original article

I've had a few people ask me to document how I set this site up so that they can spin up their own little slice of the internet. Here goes.

Write something

You'll need content first. Check out bumble and fireball for a dead-simple place to start. You'll want to keep your content in a git repo, it doesn't have to be on github but it's nice for a backup.

Get a server

Doi. Duh. You're gonna need a server out there on the internet to host your site at. I went with Digital Ocean because they came highly recommended to me by some coworkers, and they had a vm that had Dokku (and by extension Docker) on it by default.

So, go to Digital Ocean, and spin up a new droplet. I went with the smallest one due to the low traffic I expect here but choose what you think you'll need (For instance if you plan on running gitlab definitely go for at least 1GB of memory). One of the options is Select Image and this is where you click the Applications tab and choose the one that says Dokku

Make sure you add an ssh key for this (if you don't know how to make an ssh key I plan on covering that in another post).

Congratulations you now run a server on the Internet! Your droplet should have an IP, point your domain at it.

About Dokku

If you've ever used Heroku you already know how to use Dokku (mostly). It says it is a "Docker powered mini-Heroku" right in the readme, and it is! One requirement is that your site will needs to be in a git repo. One of the less well documented things in dokku is how to push to the main domain in a site instead of a subdomain. In the instructions it shows you how to add a remote to dokku@progriumapp.com:node-js-app which would respond to node-js-app.progriumapp.com. If you want your site to be at your root domain (i.e. no node-js-app) simply set the remote as dokku@yourdomain.com:yourdomain.com. If dokku sees a . in the remote path it treats it as a full domain rather than a subdomain. It may also help to set your remote to something easy to remember like blog. In my case I named my remote danger which means that to redeploy my site I simply have to type. Don't forget the Procfile!

$ git push danger master

Install dokku-apt

One of the requirements of fireball is a library called graphicsmagick. This is not on your droplet by default so you'll need a way to tell dokku to install it for your site. dokku-apt Is how you do that. Follow the instructions to install dokku-apt on your new droplet, then add an apt-packages file to the root of your site's folder with the word graphicsmagick in it.

Post post post

If you set things up right, you should be able to post

Example

If you want to check out a working example, you can check out the github repo for this very site here.

Extra credit

Technically there is no reason you should have to rebuild your dokku instance every time you push a new blog post. If you want you could try learning a few docker commands to point your dokku instance at a shared folder with your posts. Then you would simply need to update that folder w/ your new posts (maybe they're in a separate repo? maybe you scp them up?) and bumble/fireball's file watchers would automagically see them and add them to your site.

Follow up

Are you using bumble? Did this help? Did you get stuck cause I left some super crucial step out? Mash your keyboard and shout at @wraithgar.

Thanks

A huge hanks to bear for his help this weekend ironing out the kinks in this whole setup when I got stuck. And boy did I get stuck.

Also a big thanks to eric and philip for actually trying to follow the instructions in this post out. If it looks completely different now than the first time you read it, it's thanks to those two finding all the things I omitted.

When I decided to start writing again I knew I wanted to use bumble for hosting my posts. Bumble is great, it's one of those projects that is genius in its simplicity. It was started from one thought: I should just be able to have my posts in a folder in a sane format and the app should just do the rest. For a personal site like this that's all you really need. No fancy admin interface, just put the files where the app can get them and go. It runs locally very easily too, just edit, refresh, edit, and repeat until you're happy with the post.

I was greatly inspired by the talk Amber Case gave last year at Realtime Conf. You can watch it here and I highly recommend it. So, when it came time to break out the old keyboard and get this site going I knew I would ultimately want to host my own images as well as posts. Unfortunately the landscape seems pretty barren right now as far as hosting images goes.

Since my requirements were so little, it made sense to write a plugin that worked exactly like bumble, except for hosting images. That is, you point your code at a folder and they'd be hosted for you, at predictable urls for both the original and for thumbnailed versions of the file.

With those very simple, very specific requirements in mind, I sat down this weekend and wrote fireball. It's still a little rough around the edges, but it works well enough to use already. If you're using bumble, why not give it a try?^* Lemme know what you think.

^* And if you're not using bumble, why not give that a try?