yumenomatayume's blog

やる気を出す必要はない

push-to-hatenablogを使ってはてなブログ記事をGit管理してみた

ブログをmarkdownで書きたいと思い、push-to-hatenablogを導入してみました。

github.com

以前までは、記事を投稿する時は下書き用のmarkdownからコピペして整形していましたが、
導入後はmarkdownがそのまま記事として投稿できるので、とても満足しています。

さらに GitHub Actions で投稿する際の手間を出来る限り省くことで、
「メモを取る」ことから「記事を書く」までの心理的ハードルを下げることが出来ました。

普段は少しだけQiitaで情報発信する程度で、はてなブログには記事を全く投稿していませんが、
push-to-hatenablogが結構使いやすかったので、これを機に投稿を増やしていきたいと思います。

目次

push-to-hatenablogとは

はてなブログ記事の作成/取得/更新が、CLIで出来るようになります。」

導入方法は、以下のGitHubリポジトリREADME.mdに記載されています。
30分もあればpush-to-hatenablogの使い方が理解出来ると思いますので、詳細は割愛します。

以下のブログにも詳しい説明が書いてあるので、詳細はこちらを確認してください。

tanabebe.hatenablog.com

README.mdセットアップまで完了したら、push-to-hatenablogを使いやすくするためにリポジトリソースコードを修正していきます。

どのように使いやすくするのか

私のはてなブログソースコードは、以下のGitHubリポジトリで管理しています。

github.com

リポジトリのデフォルト状態を修正して、以下のようなルールで記事を管理しています。

  • はてなブログ上に保存されている記事を神様にする
    • 記事のURLのフォーマットは「タイトル」にする
  • デフォルトbranchは、記事のバックアップ専用にする
  • デフォルト以外のbranchは、はてなブログで管理されている記事の修正用にする
  • 記事の新規投稿はリポジトリにあるdraft.mdを修正する
  • はてなブログ編集画面でも編集可能にする

Before / After

以下のような流れで記事の「新規投稿」と「更新」をしています。

デフォルトからの修正点

自分のリポジトリpush-to-hatenablogリポジトリをコピーして、以下の修正を行いました。

デフォルトbranchをmainに変更

個人的に、自分のリポジトリはデフォルトbranchをmainに設定しているので、push-to-hatenablogにも同様の設定します。

GitHub上で新しくmainブランチを作成して、リポジトリの「settings」から変更することができます。

以下に詳しい方法が書いてあるので、詳細は割愛します。

qiita.com

以降の内容・ソースコードはデフォルトbranchがmainである前提で記載しています。

push.ymlの修正

まずpush.ymlについて説明すると、デフォルト以外のbranchがGitHubに作成された時に、GitHub Actionsで以下のようなworkflowが実行されます。

  • entryディレクトリの記事に差分があった場合、はてなブログで管理されている記事も更新する
  • `draft.md'が更新された場合、新規投稿する

つまり、記事の「新規投稿」と「更新」する時に使用されます。
こちらのファイルは以下を修正しました。

  • masterとなっているbranchをmainに変更
  • push前にgit config --global core.quotepath falseコマンドを実行
  • TimezoneをAsia/Tokyoに設定
  • postタスクを追加し、draft.mdに更新があった場合に新規投稿

ソースコードは以下になります。

前節でデフォルトbranchをmainに変更しましたので、それを適用します。

次にPushする前にgit config --global core.quotepath falseコマンドを追加しました。
これは、記事のURLのフォーマットを「タイトル」にしたかったので追加したコマンドになります。

はてなブログの設定で記事のURLのフォーマットを「タイトル」にした場合、Markdownのファイル名も「タイトル」そのものになります。 (厳密に言うと、空白( )はアンダースコア(_)に置き換わります)
この時に、ファイル名(タイトル)に日本語が含まれる場合、デフォルトのworkflowだとうまく動作しませんでした。

(具体的には、workflow中のgit diffコマンドで表示されるファイル名の表記が日本語にならず、差分があるファイルを特定できません)

前述のコマンドを使用することで、正しいファイル名が表示されるようになり、workflowが正常に動作します。

最後に、Timezome: Asia/Tokyoに設定しました。
これは記事を新規投稿する時に、自動的にworkflow「投稿日時」が設定されるようになっているため、日本時間になるようにしました。

CLIで新規投稿する方法もありますが、リポジトリに変更を加えただけで

pull.ymlの追加

pull.ymlは新しく追加したファイルで、push.ymlと同じディレクトリに配置します。
ソースコードは以下になります。

このGitHub Actionsを追加することにより、以下のworkflowを追加しました。

  • 定期的にはてなブログで管理している記事をデフォルトbranchにpullする
  • push.yml実行後にはてなブログで管理している記事をデフォルトbranchにpullする

このworkflowを追加した理由は、「デフォルトbranchで記事のバックアップをする」という目的があったからです。

定期的にデフォルトbranchにバックアップを実行することで、はてなブログ管理の記事をまるっとGitHubにも同期します。

workflow作成する時に注意したこと

リポジトリ更新時にデグレが発生しないように以下の注意しました。

  • cronの設定で5分ごとに実行する
  • push.ymlの後に必ず実行する
  • pullする前に、entryにある記事を削除する

定期的に実行のタイミングについて、GitHub Actionsで設定可能な最短時間である5分ごとにしています。
さらに、はてなブログ管理の記事を更新した時、即時にGitHubにも反映されるようにpush.yml実行後には必ず実行します。

最後に、pullする前にentryにある記事を削除するですが、blogsync pullを実行した時に既にentriesディレクトリが存在すると、はてなブログ上には存在しないがGitHubには存在するといったゴミが残ってしまいます。

(例えば、タイトルを変えた場合は変更前のタイトルのファイルがそのままGitHubに残ってしまいます。)

これを回避するために、こちらではPullする前にentriesディレクトリを削除するようにしています。

管理方法まとめ

まとめると、以下のようにはてなブログを管理しています。

はてなブログ記事のバックアップを更新する時(自動)

5分ごとに GitHub Actions が実行され、自動で取得されます。

GitHub Actions Action User
GitHub Actions Action User

上記のようにaction-userが記事の更新をしてくれます。
pull.ymlでcommiterやemailなどの変更もできます。

はてなブログ記事を「新規投稿」「更新」する時

まずはmainブランチに移動して、git pullをしてローカルリポジトリを更新します。

その後、ブランチを作成して記事を修正し、GitHubにpushします。
(以下ではentries/hogeブランチで記事を新規投稿 or 更新しています)

git chekckout main
git pull
git checkout -b entries/hoge

: 記事を更新する時はentryディレクトリのファイルを更新する:
: 記事を新規投稿する時はdraft.mdを修正する:

git push origin entries/hoge

GitHub Repository entries branch
GitHub Repository entries branch

pushが完了するとpullが始まって、mainブランチにも変更が適用されるので、このブランチは最後に破棄します。

画像などの詳細オプションは、ローカルのmarkdownを編集すると逆に面倒なので、ある程度記事を書いたらはてなブログ上でも編集します。

下書き記事を公開する方法

下書き記事を公開する時は、MarkdownメタデータであるDraft: trueを削除します。

さいごに

他にもGitHubはてなブログ記事を管理するツールがあるみたいです。

qiita.com

【Marp】GitHub ActionsでMarkdownからプレゼン資料を自動的に作成する

Marpとは、markdownからpdfやpptx,htmlファイルを作成することができるツールです。 以下の記事で詳しく記載されています。

zenn.dev

「なぜこの記事を書いているのか?」

上記の記事をパクってに習ってMarpの設定を試したのですが、同じエラーにハマってしまったため別の方法で設定してみました。

具体的には、DockerでMarpを動かした時に、以下のエラーが発生してしましました。

github.com

ファイルパーミッションに問題がありそうなので、以下の権限に変更して試してみましたが解消されませんでした。

chmod -R 0777 doc/

なので、GitHub ActionsにNode.jsをセットアップしてnpxでmarpを実行する方法で代用しました。

設定方法

サンプルとして、以下のリポジトリに設定しています。

github.com

設定したことは大きく分けて3つです。

  1. プレゼン用のmarkdownファイルの用意
  2. GitHub Actionsのworkflowファイル作成
  3. GitHub ActionsのConfigファイル作成

プレゼン用のmarkdownファイルの用意

任意のディレクトリにプレゼンに使用するmarkdownファイルを配置します。 サンプルだとdoc/index.mdを配置しています。

GitHub Actionsのworkflowファイル作成

使用するworkflowのファイルは以下になります。

  • PDFが文字化けしないように必要なパッケージをインストール
  • Node.jsでmarpをインストール&実行

GitHub ActionsのConfigファイル作成

使用するconfigファイルは以下になります。

このconfigはactionsで使用するものとなっており、以下パラメータとなる部分を変数化したものです。

  • markdownが置かれているディレクトリの指定
  • 変換形式(pdf,pptx,html)
  • 言語設定(基本は日本語)

プレゼン用ファイルの自動生成

上記の設定が完了したら、リポジトリgit pushされた時にGitHub Actionsが実行されます。
リポジトリの「Actions」タブに移動して、該当のworkflowに移動するとArtifactsにプレゼン用のファイルが作成されています。

Reference

zenn.dev sicklylife.jp

GitHubだけでウェブサイトの死活監視ができる【Upptime】を使ってみました

Upptimeとは、OSSの死活監視ソフトウェアです。

upptime.js.org

GitHubのサービス(GitHub Actions,GitHub Pages,GitHub Issues)のみを使って、サービスごとに以下のような死活監視を行うことができます。

使用するGitHubのサービス 機能
GitHub Actions 5分毎に特定のWebサイト監視
GitHub Pages 監視ステータスを表示するWebサイト
GitHub Issues サイトがDownした時の報告

その他にも、監視するHTTPステータスコード、Slackやメール、SMS通知などを設定することができます。

私は、サイト監視に「UptimeRobot」と言うSaaSの無料プランを使っていますが、

  • 「自身が運営しているサイトの監視をソースコード管理したい」
  • OSSで完全無料で使える監視サイトを自分で構築したい」

と言う人には「Upptime」が向いているかなと思います。

(ちなみに、UptimeRobotはこちら)

uptimerobot.com

それでは自身のリポジトリを作成して、Upptimeを構築してみます。

Upptimeを構築する

公式サイトGetting startedに沿って進めていきます。
簡単に構築することが出来て、10分あればデフォルトの状態を作成することができます。

リポジトリ作成

github.com

上記のリポジトリに移動して、「Use this template」をクリックします。

Upptime formal repotitory
Upptime formal repotitory

画面が遷移したら、以下の設定をします。

  • Repository name: 任意でOK
  • Include all branches: チェック

Create Upptime repository own from template
Create Upptime repository own from template

この状態で「Create repository from template」をクリックすると、
「Repository name」で入力した名前で、自身のリポジトリが作成されます。

作成したリポジトリに移動したら、必要な設定をしていきます。
まずはGitHubのWeb上で行う設定をしていきます。

GitHub Pages設定

UpptimeのWebサイトは、デフォルトでgh-pagesブランチに作成されます。
このブランチをGitHub Pagesで公開する設定をします。

リポジトリの「Settings」にあるGitHub Pagesの設定に移動します。
「Source: gh-pages /(root)」で「Save」をクリックします。

Setting branch of GitHub Pages
Setting branch of GitHub Pages

Secrets設定

Upptimeで使用されるGitHub Actionsでは、監視やWebサイトの作成だけでなく、リポジトリ更新も行います。

つまり、GitHub Actionsの処理中にリポジトリを編集する権限が必要になるので、Actionsで使用するPAT(Personal Access Token)を作成する必要があります。

Personal Access Token の作成

GitHubのサイトから、右上のアイコンをクリックして「Settings」を開きます。

GitHub Personal Settings
GitHub Personal Settings

次に、「Developer settings」 > 「Personal access tokens」に移動して、「Generate new token」をクリックします。

Generate Personal Access Token
Generate Personal Access Token

GitHubのパスワードが求めらるので、入力すると以下の画面になります。

Setting Personal Access Token
Setting Personal Access Token

「Note」には、何のtokenであるか分かるような名前を入力します。
(私は「upptime」とだけ入れました)

「repo」と「workflow」にチェックを入れたら、画面下までスクロールして、「Generate token」をクリックするとtokenが作成されます。

PAT Generated
PAT Generated

このtokenはリポジトリの設定に必要となるので、メモっておきましょう。

また、このtokenがあればリポジトリにアクセスできてしまうので、取り扱いには注意してください。

Repository Secrets

作成したPATをRepository Secretsに登録します。

リポジトリに戻って、「Settings」 > 「Secrets」の順に開きます。

Repository Secrets
Repository Secrets

「New repository secret」をクリックして、

  • Name: GH_PAT
  • Value: 先ほど作成したPAT

を入力し、「Add secret」をクリックします。

Add Secret
Add Secret

以上で、リポジトリに関する設定は完了です。

設定ファイルの修正

Upptimeの設定は、リポジトリ配下にある.upptimerc.ymlの1つのファイルで定義されています。
masterブランチでこのファイルを修正することで、全体の設定をすることが出来ます。

私の.upptimerc.ymlは以下のようになっています。

ここでは、Upptimeを構築する上で必須となる項目を設定していきます。
変更する箇所を抜粋したものは以下になります。

owner: ymmmtym # GitHub username
repo: upptime # GitHub repository名
sites: # 監視するサイトの名前とURLをリスト形式で書く
  - name: Google
    url: https://www.google.com
status-website:
  cname: <カスタムドメイン名> # カスタムドメインを使用しない場合はコメントアウトする
  baseUrl: /<リポジトリ名> # カスタムドメインを使用する場合はコメントアウトする
  name: Upptime # 監視サイトの名前

私の場合は、ymmtym.github.ioドメインymmmtym.comと言うカスタムドメインを使っていますが、
Upptimeには使用していないので、cnameはコメントアウトしてbaseUrlをコメントインしています。

修正する内容をまとめると以下のようになります。

項目 説明
owner GitHubのユーザ名
repo リポジトリ
sites 監視するサイトのリストを name:, url: 形式で追加
(status-website) ここから監視サイトの設定
cname カスタムドメイン
baseUrl /リポジトリ
name 監視サイト名

上記の修正をしてcommitすると、"Setup CI"というworkflowが実行され、完了するとUpptimeが構築されています。

http://<GitHubユーザ名>.github.io/<リポジトリ名>にアクセスすると、Upptimeにアクセスできます。

Upptime Top Page
Upptime Top Page

サイト監視については、Upptimeのwebサイトが更新されるだけでなくREADME.mdも更新されるので、かっこいいREADMEが勝手に作成されるところも、少し気に入っています。

Upptime README
Upptime README

また、サイトがDownするとIssueが作成されます。
HTTPステータスコードと、Response Timeも書いてありますね。

Upptime Opened Issue
Upptime Opened Issue

サイトが復旧すると自動的にIssueがCloseされます。

Upptime Closed Issue
Upptime Closed Issue

さいごに

以上でUpptimeを構築することが出来ました。
デフォルトの状態ではありますが、監視の詳細設定や通知方法なども解説できればと思います。

Reference

gigazine.net

LinuxにDockerをInstallするAnsible-Galaxy

はじめに

LinuxにDockerをインストールするたびに、

ubuntu docker install」 「centos docker install」

などをググって、Docker公式サイトより手動でインストールしていました。

毎回インストールするのは手間なので、自動化したいと思っていた矢先、 OSSで素晴らしいansible-galaxyを見つけましたので、紹介したいと思います。

使用するansible-galaxy

Ansible Playbookを書いてみる

VirtualBox上にUbuntu20.04のVMを作成します。 Vagrantを用いて、Provisioning ToolとしてAnsibleを使用し、そのPlaybookでDockerをインストールします。

Vagrantfileを作成する

以下のVagrantfileを作成します。 ホスト名はansible-dockerIPアドレス192.168.0.3/24としてあり、後ほどansibleで使用します。

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  
  config.vm.define "ansible-docker" do |node|
    node.vm.box = "bento/ubuntu-20.04"
    node.vm.hostname = "ansible-docker"
    node.vm.network "public_network", ip: "192.168.0.3", netmask: "255.255.255.0", bridge: "en1: Wi-Fi (AirPort)"
    node.vm.provider "virtualbox" do |vb|
      vb.memory = "1024"
    end
  end


  config.vm.provision "ansible" do |ansible|
    ansible.playbook = "./install_docker.yml"
    ansible.inventory_path = "./inventory.ini"
    ansible.limit = 'all'
  end

end

roleをインストールする

rolesディレクトリを作成して、その中に今回使用するroleをインストールします。

mkdir roles
ansible-galaxy install geerlingguy.docker -p roles/

InventoryとPlaybookを作る

inventory.iniを作成する

[ansible-docker]
192.168.0.3

今回のメインであるinstall_docker.ymlを作成する

---
- hosts: all
  roles:
    - role: geerlingguy.docker
      become: yes

Playbookを実行する

ディレクトリ構造は以下のようになっていると思います。

.
├── Vagrantfile
├── install_docker.yml
├── inventory.ini
└── roles
     └── geerlingguy.docker
         ├── LICENSE
         ├── README.md
         ├── defaults
         │   └── main.yml
         ├── handlers
         │   └── main.yml
         ├── meta
         │   └── main.yml
         ├── molecule
         │   └── default
         │       ├── converge.yml
         │       └── molecule.yml
         └── tasks
             ├── docker-compose.yml
             ├── docker-users.yml
             ├── main.yml
             ├── setup-Debian.yml
             └── setup-RedHat.yml

以下のコマンドでプロビジョニングしてみます。

vagrant provision

docker,docker-composeがインストールされていることを確認できました。

vagrant@ansible-docker:~$ sudo docker -v
Docker version 19.03.12, build 48a66213fe
vagrant@ansible-docker:~$ sudo docker-compose -v
docker-compose version 1.26.0, build d4451659