サービス運用

https://hexo.io/docs/#Installation npm install -g hexo-cli $ hexo help Usage: hexo <command> Commands: help Get help on a command. init Create a new Hexo folder. version Display version information. Global Options: --config Specify config file instead of using _config.yml --cwd Specify the CWD --debug Display all verbose messages in the terminal --draft Display draft posts --safe Disable all plugins and scripts --silent Hide output on console For more help, you can use 'hexo help [command]' for the detailed information or you can check the docs: http://hexo.io/docs/ hexo init <folder>は空のディレクトリに対して実行する必要がある。 いったん仮のディレクトリを作ってからコピーする。.github、.gitignoreファイルがあるのでコピー忘れに注意。 ...

Twitterは開かれすぎていて恥ずかしいし、下手な投稿をすると、エゴサする人とか、有識者とかを変に刺激して、攻撃的な反応をされることがある場所になっている。 それはとても疲れるので、そういう攻撃にさらされにくく、個人的な文章を公開できる場所がほしかった。 自分の考えを整理する機会がないので、半分自虐のお気持ち表明みたいなこともやるかもしれない。 そういう意味で、自分への免罪符と、覗きに来る人への立て札として、サイト名をVent・排気口としている（あもあすの影響）。 こういった自分の思っていることを書く文章というのは、大抵の場合、恥ずかしくなったり、書くことがなかったりで、1つ2つ書いた時点で消したり、使わなくなってしまったりする。 過去の記事タイトルや概要が一覧表示されると、恥ずかしくて消したくなってしまう。 そのあたりを考えると、細かいことを気にせずに書ける方法がいい。 はてなブログは、UIは使いやすくて好きなのけれど、PRO版でないと、はてなキーワード機能で有識者を引き寄せてしまうのが怖い。SNS化されていない場所がいい。 それならWordPressか、と思って一度VPSに立ててみたけれど、Markdownで書けない（プラグインのことは考えたくない）のがつらい。Markdownといっても、ソフトブレークなちゃんぽんだけど。 DokuWikiとかMediaWikiが向いているとは思わない。Sphinxもカテゴリ/タグ機能がない感じが微妙。 DBが必要というのはイケていない。 ならGit管理だ、GitHubだ、SSGだ、となる。 それで、なんかモダンなTypeScriptで書かれたHexoを試しに使ってみた、ということになる。 ふだんはPythonで書かれたMiyadaikuを使っているのだけれど、ユーザが少ないので、あまりいいテーマがない。 となると自作することになるのだけれど、2,3記事で爆破するかもしれないものにそこまでの労力をかけたくない。 といっても、いまこのブログもデフォルトテーマのLandscapeを使っていて、その理由はあまりいいテーマがなかったからなのだけれども。Lightはよかったけどコメント欄が消せねえ。 Git管理結構、GitHub結構、SSG結構なのだけれども、_postsディレクトリに過去の記事が全部出てくるのがイケてない。slugという仕組みとマッチしていない（なんでURLに2回日付が出てくるんですかね）。記事を作るときに記事の名前が必要なのもイケてない。 画像を追加したら、音声を追加したら、どんどんリポジトリが重くなる。まあフルクローンする機会もそうそうないか。世の中のサービスはすぐにサ終するので、外部にアップロードはしたくない。 ほかにもURLの永続性とか、いろいろ考え始めるとキリがないので、そのあたりの運用は適当になることをご承知おきいただきたい。 あまり納得のいっていないHexoから乗り換えるときにURLをリダイレクトさせるとか面倒くさいので。 あとなんか記事ジェネレータがバグっていて、生成されたmdファイルがそのままだとビルドできない（なぜか{}がfront-matterに入り込んでいて、タイトルもUTC時刻になっている） うーん、万が一この記事が攻撃の対象になったときに、言及している対象に迷惑がかからないように、とか余計なことを考えてしまう。 それだったら記事を分割して、余計な言及をあいまいにして…としたりしなかったり（戻したり）しながら書いている。とても無駄だし、とてもストレスになる。 はてなキーワードはこの意味でよくない。 記事を分割すると書くまでもない、みたいなことが拾えずに気になってしまう。 リンクを張るならnoreferrerしないと、解析に残ってしまうな…。 https://github.com/hexojs/hexo-filter-nofollow これでよさそう。 悪意があるのかないのかわからないけど、攻撃的な反応と受け取ったことで、 精神ダメージを受けている人を同時に2人観測するのはあんまりよくない（ふにちかさんとヒホさん）。 そしてこういうのがエゴサにひっかかってしまうので、noindexせざるを得ない。

https://hub.docker.com/_/wordpress docker-compose.yml version: "3.9" services: wordpress: image: wordpress:5.8.2-apache restart: always ports: - "${SERVER_PORT}:80" environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: wordpress volumes: - wordpress:/var/www/html db: image: mariadb:10.7 restart: always environment: MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress MYSQL_RANDOM_ROOT_PASSWORD: '1' volumes: - db:/var/lib/mysql volumes: wordpress: db: .env SERVER_PORT=127.0.0.1:8000

https://github.com/ArchiveBox/ArchiveBox https://hub.docker.com/r/archivebox/archivebox curl -O 'https://raw.githubusercontent.com/ArchiveBox/ArchiveBox/master/docker-compose.yml' docker-compose.yml # Usage: # docker-compose run archivebox init --setup # docker-compose up # echo "https://example.com" | docker-compose run archivebox archivebox add # docker-compose run archivebox add --depth=1 https://example.com/some/feed.rss # docker-compose run archivebox config --set PUBLIC_INDEX=True # docker-compose run archivebox help # Documentation: # https://github.com/ArchiveBox/ArchiveBox/wiki/Docker#docker-compose version: "3.9" services: archivebox: image: archivebox/archivebox:sha-f809e3b command: server --quick-init 0.0.0.0:8000 ports: - "${SERVER_PORT:-8000}:8000" environment: ALLOWED_HOSTS: "*" MEDIA_MAX_SIZE: 2g # SEARCH_BACKEND_ENGINE: sonic # uncomment these if you enable sonic below # SEARCH_BACKEND_HOST_NAME: sonic # SEARCH_BACKEND_PASSWORD: SecretPassword volumes: - "${DATA_ROOT:-./data}:/data" # To run the Sonic full-text search backend, first download the config file to sonic.cfg # curl -O https://raw.githubusercontent.com/ArchiveBox/ArchiveBox/master/etc/sonic.cfg # after starting, backfill any existing Snapshots into the index: docker-compose run archivebox update --index-only # sonic: # image: valeriansaliou/sonic:v1.3.0 # environment: # SEARCH_BACKEND_PASSWORD: SecretPassword # volumes: # - ./sonic.cfg:/etc/sonic.cfg:ro # - ./data/sonic:/var/lib/sonic/store ### Optional Addons: tweak these examples as needed for your specific use case # Example: Run scheduled imports in a docker instead of using cron on the # host machine, add tasks and see more info with archivebox schedule --help # scheduler: # image: archivebox/archivebox:latest # command: schedule --foreground --every=day --depth=1 'https://getpocket.com/users/USERNAME/feed/all' # environment: # USE_COLOR: True # SHOW_PROGRESS: False # volumes: # - ./data:/data .env SERVER_PORT=127.0.0.1:8000 DATA_ROOT=./data 初期設定 管理ユーザの作成、プライベートサーバ化、再起動。 ...

https://overleaf.com/ オンラインLaTeXエディタのShareLaTeXとOverleafは、Overleaf v2として2017年に統合され、OverleafはShareLaTeXのエディタを使うようになった。 https://www.sharelatex.com/ https://ja.overleaf.com/blog/sharelatex-joins-overleaf-2017-07-20 Overleaf（ShareLaTeX）は、overleaf.comで提供されているクラウド版と、セルフホスト可能なオープンソース版（Community Edition）が公開されている。 https://github.com/overleaf/overleaf この記事では、Overleaf Community Editionの公式Dockerイメージ（イメージ名はsharelatex/sharelatex）を使って、セルフホストする。 https://hub.docker.com/r/sharelatex/sharelatex/ クラウド版とCommunity Editionの機能の違いは、以下を参照。 https://www.overleaf.com/for/enterprises/features 使用できない機能 Git管理 Git管理やGitHub連携については、Community Editionには実装されていない（クラウド版のみ）。クラウド版のGit管理はクローズドソースなファイル履歴APIを利用して実装されており、これが技術的な課題になっているらしい。 https://github.com/overleaf/overleaf/issues/782 https://github.com/overleaf/overleaf/issues/10 Overleafに管理させないでよいのなら、ファイルは/var/lib/sharelatex/data/compiles/{project_id}-{user_id}に保存されるので、ここを監視して自動コミットするようなプログラムを使ってもいいかもしれない。 # 後者のIDがユーザIDであることの確認 docker-compose exec mongo mongo sharelatex --eval "db.users.find()" テンプレート クラウド版・Pro版限定機能。 https://github.com/overleaf/web/issues/203 https://github.com/overleaf/overleaf/issues/109 https://github.com/overleaf/overleaf/wiki/Server-Pro:-Setting-up-templates docker-compose.yml https://github.com/overleaf/overleaf/blob/a752bbefdd7ef3316aaf0c34302f08e6024aaadb/docker-compose.yml https://github.com/overleaf/overleaf/wiki/Configuring-Overleaf version: '3.9' services: sharelatex: image: sharelatex/sharelatex:3 restart: always depends_on: mongo: condition: service_healthy redis: condition: service_started ports: - "${SERVER_PORT}:80" volumes: - "${DATA_ROOT}:/var/lib/sharelatex" - "${TEXLIVE_ROOT}:/usr/local/texlive" environment: # https://github.com/overleaf/overleaf/wiki/Configuring-Overleaf SHARELATEX_APP_NAME: Overleaf Community Edition SHARELATEX_MONGO_URL: mongodb://mongo/sharelatex SHARELATEX_REDIS_HOST: redis REDIS_HOST: redis ENABLED_LINKED_FILE_TYPES: 'project_file,project_output_file' # Enables Thumbnail generation using ImageMagick ENABLE_CONVERSIONS: 'true' # Disables email confirmation requirement EMAIL_CONFIRMATION_DISABLED: 'true' # temporary fix for LuaLaTex compiles # see https://github.com/overleaf/overleaf/issues/695 TEXMFVAR: /var/lib/sharelatex/tmp/texmf-var # SHARELATEX_SITE_URL: http://sharelatex.mydomain.com # SHARELATEX_NAV_TITLE: Our ShareLaTeX Instance # SHARELATEX_HEADER_IMAGE_URL: http://somewhere.com/mylogo.png # SHARELATEX_ADMIN_EMAIL: [email protected] # SHARELATEX_LEFT_FOOTER: '[{"text": "Powered by <a href=\"https://www.sharelatex.com\">ShareLaTeX</a> 2016"},{"text": "Another page I want to link to can be found <a href=\"here\">here</a>"} ]' # SHARELATEX_RIGHT_FOOTER: '[{"text": "Hello I am on the Right"} ]' # SHARELATEX_EMAIL_FROM_ADDRESS: "[email protected]" # SHARELATEX_EMAIL_AWS_SES_ACCESS_KEY_ID: # SHARELATEX_EMAIL_AWS_SES_SECRET_KEY: # SHARELATEX_EMAIL_SMTP_HOST: smtp.mydomain.com # SHARELATEX_EMAIL_SMTP_PORT: 587 # SHARELATEX_EMAIL_SMTP_SECURE: false # SHARELATEX_EMAIL_SMTP_USER: # SHARELATEX_EMAIL_SMTP_PASS: # SHARELATEX_EMAIL_SMTP_TLS_REJECT_UNAUTH: true # SHARELATEX_EMAIL_SMTP_IGNORE_TLS: false # SHARELATEX_EMAIL_SMTP_NAME: '127.0.0.1' # SHARELATEX_EMAIL_SMTP_LOGGER: true # SHARELATEX_CUSTOM_EMAIL_FOOTER: "This system is run by department x" mongo: image: mongo:4.0 restart: always volumes: - "${MONGO_ROOT}:/data/db" healthcheck: test: echo 'db.stats().ok' | mongo localhost:27017/test --quiet interval: 10s timeout: 10s retries: 5 redis: image: redis:5 restart: always volumes: - "${REDIS_ROOT}:/data" .env SERVER_PORT=127.0.0.1:8000 DATA_ROOT=./data/sharelatex TEXLIVE_ROOT=./data/texlive MONGO_ROOT=./data/mongo REDIS_ROOT=./data/redis 設定 https://github.com/overleaf/overleaf/wiki/Quick-Start-Guide TeXLiveのフルインストール TeXLiveのフルバージョンは巨大なため、Dockerイメージには最小構成のみが含まれている。 フルバージョンを使うには、インストールコマンドを実行する必要がある。 ...

https://js.wiki/get-started 無料とは思えない多機能っぷりなWikiインフラ「Wiki.js」レビュー、自前でホスト＆外部サービスと連携可能 - GIGAZINE メモリ消費量 $ docker stats CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS e225b6b77209 wikijs_wiki_1 0.01% 127.6MiB / 7.681GiB 1.62% 13.1MB / 22.7MB 44.5MB / 1.45MB 11 13d085313406 wikijs_db_1 0.00% 44.57MiB / 7.681GiB 0.57% 6.64MB / 4.09MB 4.27MB / 102MB 8 初期状態で150-200MiB程度の消費量と思われる。 下記の環境をサーバとして、別端末からNATループバックによる接続を試したところ、ページ遷移時のロードや記事の保存に少しだけ時間がかかるように思われたが、Wikiサイト自体がなかなか開かない、というような重さではなかった。 CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz Memory: 8GB Storage: SSD OS: Ubuntu Desktop 18.04 docker-compose.yaml version: "3.9" services: db: image: postgres:13-alpine environment: POSTGRES_DB: wiki POSTGRES_PASSWORD: wikijsrocks POSTGRES_USER: wikijs restart: unless-stopped volumes: - db-data:/var/lib/postgresql/data wiki: image: requarks/wiki:2 depends_on: - db environment: DB_TYPE: postgres DB_HOST: db DB_PORT: 5432 DB_USER: wikijs DB_PASS: wikijsrocks DB_NAME: wiki restart: unless-stopped ports: - "127.0.0.1:8000:3000" volumes: db-data: https://hub.docker.com/r/requarks/wiki https://hub.docker.com/_/postgres 基本的に初期設定で問題ない。 ...

tootsuite/mastodon: Your self-hosted, globally interconnected microblogging community Mastodon documentation 内容はコミットID44d5c6bc8ffd92cd201380dabe35748e50b6af68、Mastodon Dockerイメージバージョンv3.2.1（Digest：sha256:41cd5fb48d8b15ec806f08ab06fec98df33ec9b83a1f879e0fb30da9994018dc）におけるもの。docker-composeの設定ファイルバージョンは3。 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.5 LTS Release: 18.04 Codename: bionic $ uname -r 5.4.0-56-generic $ docker -v Docker version 19.03.14, build 5eb3275d40 $ docker-compose -v docker-compose version 1.27.1, build 509cfb99 $ docker images tootsuite/mastodon --digests REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE tootsuite/mastodon v3.2.1 sha256:41cd5fb48d8b15ec806f08ab06fec98df33ec9b83a1f879e0fb30da9994018dc 37ca50fc92bd 6 weeks ago 1.86GB 今回はDocker Hub上のイメージを使用し、ローカルビルドをしない想定でいく（ごちゃごちゃするので）。 Mastodonを改造したい場合など、必要に応じてgithub:tootsuite/mastodonをFork/Cloneし、自分で/CIでビルドして信頼できるDockerレジストリに登録すればいいと思う。 ...

概要 新しく静的サイトジェネレータでブログ環境を整備した。 細かい使い方には触れないが、構成を書いておく。 静的サイトジェネレータとCI/CD 静的サイトジェネレータ 静的サイトジェネレータというのはSphinx（Python製）とかJekyll（Ruby製、GitHub Pages標準らしい）とかHugo（Go製）みたいなやつで、 MarkdownだとかreStructuredTextだとかのファイル群からHTMLを生成するツール。 Sphinx Jekyll Hugo Miyadaiku MiyadaikuはPython製の静的サイトジェネレータ。 Flaskで使うテンプレートエンジンのJinja2が使えることが特徴みたい。Jinja2はDjangoのテンプレートエンジンに似ている。 テンプレート上でどんな変数が使えるかはMiyadaikuの領域なので、ドキュメント（とサンプルテンプレート、ソースコード）を見ていくしかないかも。 github:miyadaiku/miyadaiku pypi:miyadaiku GitHub Actions GitHub上のリポジトリに対してpushやPull Requestがなされた時に事前に指定した処理を実行することのできるGitHubの機能。 Jenkinsなどに近そう。また、GitLabにも同様の機能があったはず。 GitHubのサーバで動く仮想環境上でDockerのような使い方でテストケースの実行やリリースファイルのビルド、サーバへのデプロイ、 つまりCI（Continuos Integration、テストやビルドの自動化）/CD（Continuous Delivery、デプロイの自動化）を設定できる。 Pull Requestなどへの自動ラベル付けやSlackへの通知なんかも設定することがあるのかな。 この設定はYAMLファイルとしてGitリポジトリ内に保存しますが、秘密鍵/トークンなどの情報を参照するための機能もあるみたい。 バージョン管理システム的な点ではGitは分散型なので文書自体の分散バージョン管理はできるが、 GitHubが落ちたら解消するまで（手元にリポジトリがあっても）GitHub ActionsによるCI/CDができないのが難点な気がする。 GitHub Status 考えていること レンダリング後のHTMLファイルの分離 Markdownを書いている時に見えるところに（レンダリング後の）HTMLファイルを置きたくない。 できれば何も考えずに（Markdownで書いた）メモファイルを置くのに使っていた適当なディレクトリの上でコマンドを実行したら HTTPサーバを介して（オプションで指定したテーマなどで）いい感じにレンダリングしてくれるようなものがいい （HTMLファイル自体にファイルシステムからアクセスできる必要はない）と思っていた。 このHTMLはMarkdownファイル群とレンダリングのオプションだけでいつでも生成可能なので、 レンダリング後のファイル自体が見えなければ、後からこのファイルを何かの間違いで編集してしまって正規性（再レンダリングしても差分がない状態）が崩れてしまうことがない。 それからMarkdownファイルをGitで管理する場合、レンダリング後のファイルの差分には実質的に意味がないので、（見える）commitに含めたくない気持ちがある。 この部分は適切に.gitignoreやCI/CDを設定すれば大抵の静的サイトジェネレータで実現可能だろうと思う。 今回はGitHub Actionsを使って、GitHub上の仮想環境にリポジトリから文書を読み込んでHTMLを自動生成し、文書と履歴を共有しない別ブランチ（gh-pages）に自動でcommitされるように設定する。 GitHub Actionsを動かすには.github/workflows以下にYAMLファイルを配置する。例えばこのような感じ。GitHub Pagesへのデプロイ（gh-pagesブランチの更新）にはgithub:peaceiris/actions-gh-pagesを使っている。 # deploy.yml name: Deploy # Controls when the action will run. Triggers the workflow on push or pull request # events but only for the master branch on: push: branches: [ master ] # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" build: # The type of runner that the job will run on runs-on: ubuntu-latest # Steps represent a sequence of tasks that will be executed as part of the job steps: # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: # Version range or exact version of a Python version to use, using SemVer's version range syntax. python-version: 3.x - name: Install dependencies run: pip3 install -r requirements.txt - name: Run miyadaiku-build run: miyadaiku-build --output public . - name: Deploy uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public name、runのところをコピーして増やせばコマンドを増やすことができる。 ...

https://jekyllrb.com/ Ruby製の静的ウェブサイト生成ツール（Static Site Generator）。なんかMarkdownとかで書いたサイトをいい感じにHTMLにしてくれるやつ。 Dockerイメージの準備 Ruby, RubyGems, gcc, makeが入っていれば動くらしい。公式Dockerイメージもあるみたいだけど、あえてスルーしてrubyイメージからやってみる。 ふだんRubyは使わないので試行錯誤。 https://hub.docker.com/_/ruby まずはイメージをビルド。 FROM ruby:2 WORKDIR /code RUN gem install jekyll bundler ここでgem installしてもいいのか、という問題がありそうだけどよくわからない..（キャッシュについてはいいとして） sudo docker build . -t myjekyll ひとまずこれでイメージの準備はできた。 sudo docker run --rm -v `pwd`/myblog:/code -e BUNDLE_PATH=vendor/bundle myjekyll jekyll new ./ これで./myblog（/code）に新しいJekyllプロジェクトが生成される（合わせて依存ライブラリがmyblog/vendor/bundleにインストールされる）。 vendorを除いたフォルダ構成はこんな感じ。 myblog/ ├── 404.html ├── about.markdown ├── _config.yml ├── Gemfile ├── Gemfile.lock ├── index.markdown └── _posts └── 2020-05-31-welcome-to-jekyll.markdown もし既存のプロジェクトを使う場合、bundle installでライブラリを取得する（Gemfileに書かれた依存ライブラリがmyblog/vendor/bundleにインストールされる）。 sudo docker run --rm -v `pwd`/myblog:/code -e BUNDLE_PATH=vendor/bundle myjekyll bundle install bundler、bundle execについて　※自分用メモ - Qiita 環境変数 BUNDLE_PATH の怪 - Qiita 最後に開発用サーバを立てる。 ...

※ Dockerは入ってるものとします。あとスワップ領域を用意しておいたほうがいいかな docker run --name ncdb --restart unless-stopped -v NEXTCLOUD_DIR/db:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=MY_ROOT_PASSWORD -e MYSQL_DATABASE=nextcloud -e MYSQL_USER=nextcloud -e MYSQL_PASSWORD=MY_PASSWORD hypriot/rpi-mysql --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci docker run --name ncapp --restart unless-stopped --link ncdb -p MY_PORT:80 -v NEXTCLOUD_DIR/www:/var/www/html -e MYSQL_DATABASE=nextcloud -e MYSQL_USER=nextcloud -e MYSQL_PASSWORD=MY_PASSWORD -e MYSQL_HOST=ncdb:3306 -e NEXTCLOUD_TRUSTED_DOMAINS="MY_DOMAIN" nextcloud NEXTCLOUD_DIR/www/config/config.php overwriteprotocol: 'https' overwritewebroot: '' overwrite.cli.url: 'https://MY_DOMAIN' この設定をしないとhttps環境ではクライアントからログイン（Grant access）できない（webrootはいらないかな）