1. About Personal Projects

Why emphasize that they are personal projects? Commercial projects have lengthy processes around code hosting, development, operations, and deployment. For an individual developer, such processes are too expensive and work against rapid project iteration.

A personal project might be a Demo for learning. Building a Demo in a domain is a great way to learn technology. Building a complete Demo from scratch not only exposes you to some common domain problems but also gives you a complete understanding of the domain. You see both the trees and the forest.

A personal project might also exist to satisfy a small need. For example, you want an online photo album, but public albums cannot be displayed the way you like, and they do not promise permanent service. So a need arises. You can develop the online album yourself, or modify an open-source project — either way, you have a small need.

Whatever the starting point, personal projects should be encouraged. A personal project is a programmer’s testing ground and a place to show themselves off; it both improves your skills and pleases you.

2. Open-Sourcing Your Project on GitHub

Remember this: your code is far less important than you imagine.

The vast majority of programmers merely imitate or carry over others’ results; programmers who make groundbreaking contributions are extremely rare. This is not meant to belittle imitation or carrying over — for commercial work, the core of the code is the implementation tied to business logic, and it requires no special skill. For personal projects, once freed from the constraints of business logic, open-sourcing does us no harm and brings many benefits.

• It keeps code quality in check. After all, it is a project meant to be open-sourced, so the code will certainly be reviewed by you many times.

• It enables exchange and collaborative development. Programmers all over the world are on GitHub — file your questions with issues, and develop with multiple people through PRs.

• It increases your influence. Others will need your Demo and your small features too; by sharing them, you also earn others’ approval and gain influence.

3. Containerizing a Project with Docker

Docker is simply a godsend for people who like to tinker with servers.

Before Docker, servers were always left in a mess — installing all kinds of service software and runtime environments, and before long the server disk was out of space. With Docker, you can try out all sorts of things in an isolated runtime environment.

Docker uses technologies such as lxc, cgroup, and namespace to virtualize a runtime on the host machine, providing virtual machine services that can start and stop within seconds. Compared with virtual machines such as VirtualBox and VMWare, Docker is more lightweight and uses resources more efficiently.

Containerizing a project with Docker takes only three steps:

• You need a suitable base image

• Mount directories

• Expose service ports

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 需要合适的基础镜像
FROM node:6

RUN mkdir -p /var/www/app
WORKDIR /var/www/app

# 挂载目录
ADD . /var/www/app
RUN rm -rf /var/www/app/resources/photos/* /var/www/app/config.js

# 暴露服务端口
EXPOSE 3000

RUN npm install -g cnpm --registry=https://registry.npm.taobao.org && return 0
RUN cnpm install

CMD ["cnpm", "run", "start"]

The above is the Dockerfile I wrote for an application I recently Dockerized. To speed up dependency installation, I used cnpm.

4. Publishing Images with hub.docker.com

The benefit of hosting your code on GitHub is that you can conveniently use all kinds of surrounding services — for example, Travis CI for continuous integration. What I want to bring up here is the image build feature provided by hub.docker.com.

After registering an account on hub.docker.com, create a project and link it to your GitHub project. Each time you push code to GitHub, it triggers an image build job on hub.docker.com. The built image can also be used by others at the same time.

5. Hosting Deployment Scripts in a Private GitLab Repository

For configurations that contain private information, GitLab is a good choice. A free GitHub account can only create public projects, whereas a free GitLab account can also create private projects.

Hosting project configuration and deployment scripts in a private GitLab repository both guarantees privacy and records changes to the configuration and scripts.

Add GitLab CI on top of that, and GitLab really becomes more and more likeable the more you use it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

version: '2'

services:

    nginx:
      image: shaowenchen/docker-nginx:latest
      restart: always
      privileged: true
      links:
        - gallery
      volumes:
        - ./www/:/var/www/
      ports:
        - "80:80"
      depends_on:
        -  gallery

    gallery:
      image: shaowenchen/zing-gallery:latest
      restart: always
      volumes:
        - ./www/resources/photos:/var/www/app/resources/photos
        - ./www/conf/config.js:/var/www/app/config.js

The above is a service I recently orchestrated with docker-compose. All it takes is a single docker-compose.yml file plus some configuration files, and on any server you can bring the service up with one command, docker-compose up -d.

6. Monitoring the Service

There are two ways to monitor a service:

• The first is through logs. Deploying ELK records runtime and access logs well, and you can build a monitoring and alerting system around log keywords.

• The second is a monitoring system. Deploying Prometheus and Bosun enables effective monitoring of the service.

If you find that too much trouble, there is another, more convenient route: use DaoCloud. Install the DaoCloud Agent, and once the host is hosted on DaoCloud, you can view and deploy services in real time and keep an eye on how the server is running.