2021-09-12

docker/build-push-action@v2 のキャッシュ方法は cache.md を読むと参考になる

※本記事は docker/build-push-action@v2.7時点の情報を元に記述しています。

結論、cache.md とは次のことです。
build-push-action/cache.md at v2.7.0 · docker/build-push-action · GitHub

ほか、背景や調べたことをつらつらメモ書きしておきます。

背景

副業で Ruby on Rails の CI 環境を作る上で次の記事が参考になりました。

techracho.bpsinc.jp

しかし残念なことに、buildx/BuildKitランナーをVMのコンテキストでセットアップする（つまりDockerのキャッシュがエクスポート可能になり、正しくキャッシュできる）驚くほどシンプルな方法が存在するにもかかわらず、このドキュメントにはそのことが記載されていないのです。

以下は、docker/build-push-actionリポジトリから引用した公式なサンプルです。

前述にて、Local cacheを利用したワークフローのサンプルおよび、docker/build-push-action を利用したキャッシュ方法が記述されたリンクが紹介されています。

build-push-action/cache.md at v2.7.0 · docker/build-push-action · GitHub

Ruby on Rails に限らず、GitHub Actions 上で Docker build する機会がある場合、前述のサンプルが大いに参考になると思います。

cache-from, cache-to などの記述は Buildx のドキュメントを参考にする

GitHub Action to build and push Docker images with Buildx with full support of the features provided by Moby BuildKit builder toolkit. This includes multi-platform build, secrets, remote cache, etc. and different builder deployment/namespacing options.

と About 記載されている通り docker/build-push-action@v2 は Buildx を利用して Build, Push, Cache などの Docker に関する操作が行われています。

Buildx とは docker build を強化するプラグイン。前述の記事内などで記述されている cache-from / cache-to など、キャッシュの読み書き先を指定など、色々できるみたいです。

お世話になった記事

2021-06-13

「他人と自分を比較する」は生存本能として正常だから、卑屈にならなくて良いかも / 「生命科学的思考」を読んだ

感想思考方法

たまには、エンジニアから離れて別職種の視点から物事を見たいと思い、手に取りました。

ビジネスと人生の「見え方」が一変する生命科学的思考 (NewsPicksパブリッシング)

作者:高橋祥子
ニューズピックス

Amazon

作者は、遺伝子検査のサービスを提供している会社の経営者です。

genequest.jp

経営者かつ研究者であることから、専門的な知識でありながら、遺伝子・生物学に詳しくない自分にもわかりやすく解説してくれるだろうと、感じました。

概要
- 目次
- ターゲット
感想

概要

次の点について、生命原則や遺伝子の科学的視点＆作者の考え方が書かれていました。

なぜ人間は「感情」を持っているのか
なぜ人間は視野が狭いのか
幸福と快楽の違い / 快楽に手を出してしまうのはなぜか
情熱の原理

第1章　生命に共通する原則とは何かー客観的に捉えるー
第2章　生命原則に抗い、自由に生きるー主観を活かすー
第3章　一度きりの人生をどう生きるかー個人への応用ー
第4章　予測不能な未来へ向け組織を存続させるにはー経営・ビジネスへの応用ー
第5章　生命としての人類はどう未来を生きるのか

ターゲット

書籍内で推奨されている方です。

怒りや悲しみなどネガティブな感情に流されたくない
意志を強く持ち続けたい
組織作りやビジネスに生命科学の知見を応用したい
チームや人間関係のことで悩んでいる
何かに打ち込むための情熱がほしい

感想

書籍で気になったポイントや影響を受けたことについて書きます。

色々な書籍を読んでも、自己肯定感の低さから抜け出せない方にオススメかと思います。

[影響] 「他人と自分を比べる」に対して、負の感情がなくなった（かもしれない）

不安・怒りといった負の感情は、遺伝子に組み込まれている生存本能によるものであると書かれています。

私は自己肯定感の低さに悩んでいました。さまざまな書籍や壁打ちによって、自己肯定感が一時的に高くなりましたが、自分より優れた人間を見たときに「他人と自分を比べる」を考え、実力差から劣等感を感じ、自己肯定感の低さから解放されずにいました。

「他人と自分を比べる」という考え方は、人間の遺伝子として正常な反応（生き残る上で自分に何が足りないか考えている）であると書籍で解説されていました。「他人と自分を比べる」は正常な反応と肯定されたことで、次のように考えるようになりました。

「他人と自分を比べる」 -> 「自分が生き残るため、他人のスキルを分析している」と解釈するようになった
- 実力差から劣等感を生む害悪から、生き残るために発動するスキルになった
「他人と自分を比べる」を正常なこととして解釈することで、劣等感がなくなった（かもしれない）

（かもしれない）と記載したのは、この考えに至ってから1ヶ月ほどしか経っていないためです。1年くらい劣等感に悩むことがなくなったら、（かもしれない）を削除するかもしれません。

[気になったポイント] 思考停止はコスパ良し

考えることは、脳にとって大きなエネルギー消費となるため、思考停止はエネルギー消費を抑えようとする生存本能の正常反応だそうです。

仕事や勉強・創作活動といった生存本能に抗って活動されている方は、その行動力だけでもえらい！って考えると気持ちが楽になりそうです。

お仕事の人とコウペンちゃん pic.twitter.com/l8Nowlka2h
— るるてあ (@k_r_r_l_l_) 2018年1月30日

[気になったポイント] その他

色々書くとネタバレになりそうなので、気になったキーワードを並べておきます。

情熱は未来差分と初速から生まれる
- 意識高い＝初速がある（行動している）人、意識高い系の人＝初速がない（行動していない）人の表し方はわかりやすかった
思考停止の反対 -> 命を燃やす
- コーヒーにミルクを入れるとかき混ぜなくても混ざる様と同じく、人も環境に依存して思考停止 or 命を燃やすにつながりやすい
  - エントロピー増大則の様と似ているらしい -> 図解！エントロピー増大の法則とは？自発変化の方向を示す熱力学の金字塔 - Dreamscope Blog
- 思考停止を脱したい（命を燃やしたい）場合はどうすれば？
  - カオスな環境に身を投じるのもあり -> 転職など
  - がむしゃらにチャレンジすると決め、未来差分と初速を持って情熱を生み出して取り組む

2021-05-26

@nuxt/content でブログつくったという近況報告

Vue.js Nuxt.js プログラミング個人開発ブログ

2ヶ月ぶりの投稿です。

zaki-blog という、雑に書くブログをつくったので、その報告です。

ブログ作ったきっかけ

雑記ブログはじめましたという記事に書きました。

概要は次のような感じ。

自分の砂場が欲しかった
考え、趣味を気軽に吐き出したかった

使用技術

`@nuxt/content`

昨年末の UIT INSIDE ep.71 をきっかけに @nuxt/content という Nuxt.js の SSG (静的サイト生成)ライブラリの存在を知りました。

uit-inside.linecorp.com

content.nuxtjs.org

ブログつくるまでのコストが低そうだったので、使わせていただきました。

Composition API の素振りもしたくて、@nuxtjs/composition-api も導入しました。

composition-api.nuxtjs.org

ホスティング Vercel

Next.js との連携が協力で有名な Vercel にホスティングさせてます。

vercel.com

Netlify でもよかったのですが、Vercel でどういう設定ができるか試したかったのが理由です。

参考サイト

ブログ自作されている
@nuxt/content 使っている

主に前述に当てはまる方のリポジトリに参考にしています。
（自分のブログデザイン等が k● なのは、参考サイトのせいです。）

もっとさんの React, GatsbyJS の本も参考にしました。

React & GatsbyJS開発入門 - mottox2（つのぶえ出版） - BOOTH

最終的に自分が使用したのは、現スキルに応用が効く Nuxt.js ですが、コードベース x SSG でブログを作成する上で、参考となる知見が書かれている本でお世話になりました。

これからやること

feed.xml の id を Atom の仕様通りにする
OGP対応
Tailwind 抜く（かは検討中）

とか、いろいろありますが、無理せずやっていきたいと思います。

2021-03-07

eslint-config-prettier@8.0 から prettier/hogehoge -> prettier だけ記載すれば良さそう

Node.js プログラミング JavaScript

とあるリポジトリで npm-check-updates したところ eslint-config-prettier が v7 -> v8 にバージョンアップしていたことを知りました。

eslint-config-prettier/CHANGELOG.md#version-800-2021-02-21の

Changed: All configs have been merged into one!

と記載されている部分を確認すると

{
    "prettier",
    "prettier/@typescript-eslint",
    "prettier/vue"
}

のように prettier/hogehoge と書いていた部分の設定が

{
    "prettier"
}

と、prettier に集約していただいたみたいです。
（pretterまわりの設定が楽になって助かります...）

おわり（所感）

短いですが、メモ記事です。
間違い等ありましたら、コメント等から指摘いただけると助かります。 🙏

`prettier-eslint`

blog.ojisan.io

前述の記事を拝見し prettier-eslint に移るべきだよなぁと思いつつ、個人用の検証リポジトリ等では、いまだ eslint-config-prettier を使い続けています...。（npx eslint --fix src でまとめて整形＆チェックするのが楽でorz）

2021-03-05

【Django 3.1】ForeignKey や OneToOneField で指定した参照先モデルのマネージャを指定するには Base Manager を変更する

Python Django プログラミング

Django 3.1¹ において、複数データベースを使い分ける手段を調べていたときに Default Manager Base Manager の存在を知りました。時間が経つと存在自体忘れそうなため、自分用にメモしときます。

認識齟齬等ありましたら、コメント等いただけると幸いです。 🙏

複数データベースを利用する

複数のデータベース | Django ドキュメント | Django に記載されている通り、settings.py に default 以外のデータベース情報を定義し、

DATABASE_ROUTERSの仕組みを使う
QuerySetやsaveする際にusingを指定する
db_managerを使用する
CustomManger を定義し、get_querysetで接続先を指定する

ような方法があるのかな、と思います。

参考リソース

検証用コードが載っている記事がありました。

利用するDjangoのバージョンに注意しながら、参考にすると良さそうです。

Default Manger と Base Manager

リファレンスにDefault MangerとBase Mangerの説明が記載されています。

Default Manager は object の代わりに Custom Manger を指定。
Base Manger は ForeignKey や OneToOneField で参照しているモデルで使用されるマネージャを指定...と解釈しています。

コード

リファレンスを見る限り Meta.default_manager_name Meta.base_manager_name を指定するっぽいです。

ざっくり書き起こすと、以下のようなイメージです。

from django.db import models


class GeneralUserManager(models.Manager):
    def get_queryset(self):
        return super().get_queryset().filter(owner=False)


class User(models.Model):
    description = models.TextField()
    owner = models.BooleanField(default=False)

    objects = GeneralUserManager()  # owner=True な User が抽出される
    owner_objects = models.Manager()  # すべての User が抽出される
    class Meta:
        base_manager_name = 'owner_objects'  # PcSkill から user.description のように参照される場合、指定されたマネージャが使用される


class PcSkill(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='pc_skill')
    level = models.IntegerField()

このようなモデルやマネージャを定義しておき...

skill = PcSkill.objects.get(pk=1)
skill.user.description

skill.user.description のように関連オブジェクトを参照した際、UserのMeta.base_manager_nameに指定した"owner_objects"が選択されます。

カスタムマネージャは、上記サンプルコードのようにfilterしたり、usingやdb_managerを用いてデータベースの切り替えたりできます。

関連するオブジェクトから使用するマネージャをカスタムマネージャに変更したい場合は、Meta.base_manager_nameに指定すると良さそうです。

※ Meta.default_manager_name Meta.base_manager_name は、正しくは Option.default_manager_name Option.base_manager_nameです。
　コードで説明するため、あえて Meta と書いています。

おわり

以上です。

繰り返しになりますが、認識齟齬等ありましたら、コメントなどフィードバックいただけると助かります 🙏

本記事執筆時点では 1.11〜3.1 まで有効な設定であることを確認済です。↩

ざきの学習帳

日々の学びを書きます