push-to-hatenablogを使ってはてなブログ記事をGit管理してみた
ブログをmarkdownで書きたいと思い、push-to-hatenablogを導入してみました。
以前までは、記事を投稿する時は下書き用のmarkdownからコピペして整形していましたが、
導入後はmarkdownがそのまま記事として投稿できるので、とても満足しています。
さらに GitHub Actions で投稿する際の手間を出来る限り省くことで、
「メモを取る」ことから「記事を書く」までの心理的ハードルを下げることが出来ました。
普段は少しだけQiitaで情報発信する程度で、はてなブログには記事を全く投稿していませんが、
push-to-hatenablogが結構使いやすかったので、これを機に投稿を増やしていきたいと思います。
目次
push-to-hatenablogとは
「はてなブログ記事の作成/取得/更新が、CLIで出来るようになります。」
導入方法は、以下のGitHubリポジトリのREADME.md
に記載されています。
30分もあればpush-to-hatenablogの使い方が理解出来ると思いますので、詳細は割愛します。
以下のブログにも詳しい説明が書いてあるので、詳細はこちらを確認してください。
README.md
のセットアップまで完了したら、push-to-hatenablogを使いやすくするためにリポジトリのソースコードを修正していきます。
どのように使いやすくするのか
私のはてなブログのソースコードは、以下のGitHubリポジトリで管理しています。
リポジトリのデフォルト状態を修正して、以下のようなルールで記事を管理しています。
- はてなブログ上に保存されている記事を神様にする
- 記事のURLのフォーマットは「タイトル」にする
- デフォルトbranchは、記事のバックアップ専用にする
- デフォルト以外のbranchは、はてなブログで管理されている記事の修正用にする
- 記事の新規投稿はリポジトリにある
draft.md
を修正する - はてなブログ編集画面でも編集可能にする
Before / After
以下のような流れで記事の「新規投稿」と「更新」をしています。
デフォルトからの修正点
自分のリポジトリにpush-to-hatenablogのリポジトリをコピーして、以下の修正を行いました。
デフォルトbranchをmainに変更
個人的に、自分のリポジトリはデフォルトbranchをmainに設定しているので、push-to-hatenablogにも同様の設定します。
GitHub上で新しくmainブランチを作成して、リポジトリの「settings」から変更することができます。
以下に詳しい方法が書いてあるので、詳細は割愛します。
以降の内容・ソースコードはデフォルトbranchがmainである前提で記載しています。
push.yml
の修正
まずpush.yml
について説明すると、デフォルト以外のbranchがGitHubに作成された時に、GitHub Actionsで以下のようなworkflowが実行されます。
つまり、記事の「新規投稿」と「更新」する時に使用されます。
こちらのファイルは以下を修正しました。
- 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を追加しました。
この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 が実行され、自動で取得されます。
上記のように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
pushが完了するとpullが始まって、mainブランチにも変更が適用されるので、このブランチは最後に破棄します。
画像などの詳細オプションは、ローカルのmarkdownを編集すると逆に面倒なので、ある程度記事を書いたらはてなブログ上でも編集します。
下書き記事を公開する方法
下書き記事を公開する時は、MarkdownのメタデータであるDraft: true
を削除します。
さいごに
【Marp】GitHub ActionsでMarkdownからプレゼン資料を自動的に作成する
Marpとは、markdownからpdfやpptx,htmlファイルを作成することができるツールです。 以下の記事で詳しく記載されています。
「なぜこの記事を書いているのか?」
上記の記事をパクってに習ってMarpの設定を試したのですが、同じエラーにハマってしまったため別の方法で設定してみました。
具体的には、DockerでMarpを動かした時に、以下のエラーが発生してしましました。
ファイルパーミッションに問題がありそうなので、以下の権限に変更して試してみましたが解消されませんでした。
chmod -R 0777 doc/
なので、GitHub ActionsにNode.jsをセットアップしてnpx
でmarpを実行する方法で代用しました。
設定方法
サンプルとして、以下のリポジトリに設定しています。
設定したことは大きく分けて3つです。
プレゼン用のmarkdownファイルの用意
任意のディレクトリにプレゼンに使用するmarkdownファイルを配置します。
サンプルだとdoc/index.md
を配置しています。
GitHub Actionsのworkflowファイル作成
使用するworkflowのファイルは以下になります。
- PDFが文字化けしないように必要なパッケージをインストール
- Node.jsでmarpをインストール&実行
GitHub ActionsのConfigファイル作成
使用するconfigファイルは以下になります。
このconfigはactionsで使用するものとなっており、以下パラメータとなる部分を変数化したものです。
プレゼン用ファイルの自動生成
上記の設定が完了したら、リポジトリにgit push
された時にGitHub Actionsが実行されます。
リポジトリの「Actions」タブに移動して、該当のworkflowに移動するとArtifactsにプレゼン用のファイルが作成されています。
Reference
GitHubだけでウェブサイトの死活監視ができる【Upptime】を使ってみました
Upptimeとは、OSSの死活監視ソフトウェアです。
GitHubのサービス(GitHub Actions,GitHub Pages,GitHub Issues)のみを使って、サービスごとに以下のような死活監視を行うことができます。
使用するGitHubのサービス | 機能 |
---|---|
GitHub Actions | 5分毎に特定のWebサイト監視 |
GitHub Pages | 監視ステータスを表示するWebサイト |
GitHub Issues | サイトがDownした時の報告 |
その他にも、監視するHTTPステータスコード、Slackやメール、SMS通知などを設定することができます。
私は、サイト監視に「UptimeRobot」と言うSaaSの無料プランを使っていますが、
と言う人には「Upptime」が向いているかなと思います。
(ちなみに、UptimeRobotはこちら)
それでは自身のリポジトリを作成して、Upptimeを構築してみます。
Upptimeを構築する
公式サイトのGetting startedに沿って進めていきます。
簡単に構築することが出来て、10分あればデフォルトの状態を作成することができます。
リポジトリ作成
上記のリポジトリに移動して、「Use this template」をクリックします。
画面が遷移したら、以下の設定をします。
- Repository name: 任意でOK
- Include all branches: チェック
この状態で「Create repository from template」をクリックすると、
「Repository name」で入力した名前で、自身のリポジトリが作成されます。
作成したリポジトリに移動したら、必要な設定をしていきます。
まずはGitHubのWeb上で行う設定をしていきます。
GitHub Pages設定
UpptimeのWebサイトは、デフォルトでgh-pagesブランチに作成されます。
このブランチをGitHub Pagesで公開する設定をします。
リポジトリの「Settings」にあるGitHub Pagesの設定に移動します。
「Source: gh-pages /(root)」で「Save」をクリックします。
Secrets設定
Upptimeで使用されるGitHub Actionsでは、監視やWebサイトの作成だけでなく、リポジトリ更新も行います。
つまり、GitHub Actionsの処理中にリポジトリを編集する権限が必要になるので、Actionsで使用するPAT(Personal Access Token)を作成する必要があります。
Personal Access Token の作成
GitHubのサイトから、右上のアイコンをクリックして「Settings」を開きます。
次に、「Developer settings」 > 「Personal access tokens」に移動して、「Generate new token」をクリックします。
GitHubのパスワードが求めらるので、入力すると以下の画面になります。
「Note」には、何のtokenであるか分かるような名前を入力します。
(私は「upptime」とだけ入れました)
「repo」と「workflow」にチェックを入れたら、画面下までスクロールして、「Generate token」をクリックするとtokenが作成されます。
このtokenはリポジトリの設定に必要となるので、メモっておきましょう。
また、このtokenがあればリポジトリにアクセスできてしまうので、取り扱いには注意してください。
Repository Secrets
作成したPATをRepository Secretsに登録します。
リポジトリに戻って、「Settings」 > 「Secrets」の順に開きます。
「New repository secret」をクリックして、
- Name: GH_PAT
- Value: 先ほど作成したPAT
を入力し、「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のwebサイトが更新されるだけでなくREADME.md
も更新されるので、かっこいいREADMEが勝手に作成されるところも、少し気に入っています。
また、サイトがDownするとIssueが作成されます。
HTTPステータスコードと、Response Timeも書いてありますね。
サイトが復旧すると自動的にIssueがCloseされます。
さいごに
以上でUpptimeを構築することが出来ました。
デフォルトの状態ではありますが、監視の詳細設定や通知方法なども解説できればと思います。
Reference
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-docker
、IPアドレスは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