0%

Hexo provides a fast and easy deployment strategy. You only need one single command to deploy your site to your server.

1
hexo deploy

To deploy Hexo to Github, you need to install the necessary plugin(s), hexo-deployer-git that is compatible with the deployment method provided by your server/repository. Deployment is usually configured through _config.yml. A valid configuration must have the type field. For example:

1
2
deploy:
type: git

At the beginning, you need to go to this website to see how to create a GitHub Personal Access Token. Once the token is generated, keep it somewhere for later use.

Go to Hexo file _config.yml, and include below code block in it. Set the token parameter to be the Github token name which was just generated.

1
2
3
4
5
6
7
8
9
deploy:
type: git
repo:
github:
url: https://github.com/<myusername>/<myrepo>.git
branch: <branch_name>
token: $<token_name>
name: <my_visible_name>
email: <my_email>

After this, you could deploy Hexo to your Github repository. The command should be like this:

1
<token_name>=<token_value> hexo deploy;

What is S3 ?

  • Object Based
  • Files <= 5 TB
  • No OS or DB storage
  • Unlimited Storage
  • Universal namespace

What is S3 Object?

  • Key * Object name
  • Value * The data itself (made up of bytes)
  • Version ID
  • Metadata * Data about the data you are storing

S3 Security

  • Buckets are private by default (includes all objects within it)
  • Object ACLs: Make individual objects public
  • Bucket policies: Make entire buckets public
  • HTTP status code: When uploading an object to S3 successfully

S3 Versioning

  • All Versions: All Versions of an object are in S3. (writes and deletes)
  • Backup: a great backup tool
  • Cannot Be Disabled: Once enabled, it cannot be disabled * only suspended
  • Lifecycle Rules: Can be integrated with lifecycle rules
  • Supports MFA: Can support multi-factor authentication

S3 Lifecycle Management

  • Automates moving objects between the different storage tiers
  • Can be used in conjunction with versioning
  • Can be applied to current versions and previous versions

S3 Object Lock and Glacier Vault Lock

  • Object Lock
    • Store objects using a write once, read many (WORM) model
    • Can be on individual objects or applied across the bucket
    • It comes in two modes: governance mode (protect objects against most users unless they have special permissions) & compliance mode (protect objects against any users)
  • Glacier Vault Lock
    • Allows you to deploy and enforce compliance controls for individual S3 Glacier vaults with a vault lock policy. You can specify controls, e.g. WORM, in a vault lock policy and lock the policy from future edits. Once locked, the policy cannot be changed

S3 Encryption

  • Encryption in Transit
    • SSL/TLS
    • HTTPS
  • Encryption at Rest
    • Server-side encryption
    • SSE-S3 (AES 256-bit)
    • SSE-KMS
    • SSE-C
  • Client-Side Encryption
    • Encrypt the files before you upload them to S3
  • Encryption with a Bucket Policy
    • A bucket policy can deny all PUT requests that do not include the x-amz-server-side-encryption parameter in the request header

Optimizing S3 Performance

  • Prefix
    • More prefix and more requests per second.
    • You can achieve a number of requests: 3,500 PUT / COPY / POST / DELETE and 5,500 GET / HEAD per second , per prefix
  • SSE-KMS limits * when using it to encrypt objects in S3, keep in mind the limits
    • Uploading/downloading count toward the KMS quota
    • Region-specific, it’s either 5,500, 10,000 or 30,000 requests per second
    • You cannot request a quota increase for KMS
  • Tips:
    • Use multipart uploads to increase performance when uploading files
    • Files > 100 MB (should use multipart uploads). Files > 5 GB (must use multipart uploads)
    • User S3 byte-range fetches to increase performance when downloading files

S3 Replication

  • Replicate objects from one bucket to another
  • Existing objects are not replicated automatically
  • Delete markers are not replicated by default

S3 Comparison

While using Hexo to set up a github.io blog, the default domain name is [your-github-username].github.io. To use a custom DNS for your personal blog, Github requires you to create a file named CNAME in master branch of your repository. Since Hexo3, if you simply added the CNAME file manually it would be overwritten at deployment time. So you could use Hexo plugin: hexo-generator-cname.

Install

1
$ npm install hexo-generator-cname --save

Enable

Add hexo-generator-cname to plugins in _config.yml.

1
$ plugins: hexo-generator-cname

Configure domain name

Go to _config.yml file, and find the variable url. Configure your custom domain name like below.

1
url: http://[your-custom-domain-name]

When you run

1
$ hexo generate

again, a CNAME file containing your custom domain name configured just now in _config.yml will be created.

Then you need to login to your DNS provider and create a DNS CNAME record pointing hostname www to your-github-username.github.io. Here is a DNS provider I used before wanwang. It will take a couple hours to replicate default domain name with the custom one.

Welcome to Hexo! This is a short post about how to use Hexo. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask questions on GitHub.

Quick Start

Create a new post

1
$ hexo new "My New Post"

More info: Writing

Writing a post

You need to use Markdown language to write posts. Please go to this website to learn the syntax.

Run server

1
$ hexo server

More info: Server

Generate static files

1
$ hexo generate

More info: Generating

Deploy to remote sites

1
$ hexo deploy

More info: Deployment