Stella Dev

Container・Image・Volumeから始めるDocker入門

Wed, 10 Jun 2026 00:00:00 GMT

3つのキーワードからDockerを始める

Dockerを使い始めたので、学んだことをメモします。

DockerにはWeb制作とは異なる概念や用語が数多く登場するため敷居が高いと感じました。いろいろ調べていくうちに、3つのキーワードが浮かんできました。それは、Container, Image, Volumeです。

これらの概念から考えると理解しやすかったので、この記事ではこの3つを起点に内容をまとめていきます。

Container, Image, Volume それぞれの役割

Container

Imageから作成されるアプリの実行環境。ホストOSから隔離され、任意に起動・停止・削除ができます。削除するとデータも消えるため、残すべきデータはVolumeに保存します。

Image

Containerを作成するための「設計図」。コンテナの実行に必要なファイル群（OS・ライブラリ・アプリなど）をまとめたものです。Docker Hubから公式イメージを取得することもできます。自分で作成する方法もあります（この記事では割愛します）。

Volume

コンテナを削除してもデータを残すための仕組み。コンテナ内の特定ディレクトリをMacのフォルダへ引き出すことで、投稿・テーマなど大切なデータを永続化し続けます。

3つの概念の関係を図にすると次のようになります。（WordPressを例として使います）

WordPressで学ぶ、Docker環境の構築手順

例として、「WordPressの環境」を作る場合の手順を整理します。

Step 1 : Container と Image を決める

WordPressを動かすために必要なものを分解し、各コンテナに対応するImageを選びます。

WordPress環境に必要なもの
  ├── Webサーバー（Apache）
  ├── PHP
  ├── WordPress本体
  └── データベース（MySQL）

公式の wordpress イメージはApache + PHP + WordPress本体が1つにまとまっています。そのため必要なコンテナは以下の2つになります。

wordpressコンテナ  ← wordpress 公式イメージ（Docker Hub）
mysqlコンテナ      ← mysql 公式イメージ（Docker Hub）

自作不要で、公式Imageがそのまま使えます。

Step 2 : Volume を設計する

Containerを作り直した時、WordPressのテーマファイルや投稿データが消えてしまうと困ります。永続化したいデータはVolumeとして保存することができます。

テーマ・プラグイン・画像 → wp-content/ → 保存したい
投稿・ユーザーデータ → /var/lib/mysql → 保存したい
wp-admin/など → WordPressコア → Imageに入っているので保存しなくていい

2つのVolumeが必要とわかります。

Step 3: docker-compose.yml を書く

docker-compose.yml とは、複数のコンテナの構成を1つのファイルにまとめたものです。使う Image、ポート、環境変数、Volume などを書いておけば、docker compose up で環境全体をまとめて起動できます。

Step 1、2 で決めた内容は次のとおりです。

Container: wordpress と mysql の2つが必要
Image: 公式イメージをDocker Hubから取得して使う
Volume: wp-content とデータベースを永続化する

services: # 起動するコンテナ（サービス）の一覧

  wordpress: # WordPress 用コンテナの定義
    image: wordpress:latest # 使用する Docker イメージ（公式 WordPress、常に最新版）
    ports:
      - "8080:80" # ホストの 8080 番 → コンテナ内の 80 番（http://localhost:8080 でアクセス）
    environment: # WordPress コンテナ内の環境変数（DB 接続設定）
      WORDPRESS_DB_HOST: mysql # DB のホスト名（下の mysql サービス名と一致させる）
      WORDPRESS_DB_NAME: wordpress # 接続先データベース名
      WORDPRESS_DB_USER: wp_user # DB 接続用ユーザー名
      WORDPRESS_DB_PASSWORD: wp_pass # DB 接続用パスワード
    volumes:
      - ./wp-content:/var/www/html/wp-content # テーマ・プラグイン・アップロードをホスト側に永続化
    depends_on:
      - mysql # mysql コンテナの起動後に wordpress を起動する

  mysql: # MySQL 用コンテナの定義
    image: mysql:8.0 # 使用する Docker イメージ（MySQL 8.0 系）
    environment: # MySQL コンテナ内の環境変数（DB 初期化設定）
      MYSQL_DATABASE: wordpress # 起動時に自動作成するデータベース名
      MYSQL_USER: wp_user # 上記 DB 用に作成するユーザー名
      MYSQL_PASSWORD: wp_pass # 上記ユーザーのパスワード
      MYSQL_ROOT_PASSWORD: root_pass # MySQL 管理者（root）のパスワード
    volumes:
      - ./db-data:/var/lib/mysql # DB データをホスト側に永続化（コンテナ削除後も残る）

※実際の運用では、環境変数は.envから読み込むなどの秘匿化をします。

Step 4: Containerを起動する

docker-compose up -d #コンテナを作成して起動 -dオプションを付けるとターミナルのバックグラウンドで実行

localhost:8080 をブラウザで開くとWordPressのセットアップ画面が表示されます。停止や再スタートは以下のコマンドです。

docker-compose stop     # 停止（コンテナは残る）
docker-compose start    # 作成済みで停止中のコンテナを起動
docker-compose down     # 停止してコンテナを削除

stop と down の違いは、コンテナを残すかどうかです。設定を変えて作り直したいときは down を使います。

まとめ

Container, Image, Volumeに絞って考えて理解を深めてみました。

今回は image: wordpress:latest のように、Docker Hubにある公式Imageをそのまま使いましたが、環境やライブラリを追加したい場合は Dockerfile を作成しカスタマイズできます。

Desktopアプリの導入についても省いていますし、まだまだ知らないことがたくさんあるはずです。勉強あるのみですね！

余談: Containerはなぜ作ったり削除したりするのか？

この疑問に対する回答を上手くまとめられなかったので、AIに聞いてみました。

:::note[AIの回答] Containerは起動中にファイルが書き換わったり、設定が変わったりすることがあります。しかしImageという設計図があれば、いつでも同じ状態のContainerを作り直せます。

そのため、Dockerでは「直す」より「作り直す」という考え方をとります。

従来のサーバー管理	Dockerのやり方
壊れたら修復する	削除して作り直す
環境の設定が蓄積していく	毎回クリーンな状態から始まる
復旧に時間がかかる	Imageがあれば数秒で再作成

また、設定を変えたい場合も同様です。環境変数やポート番号を変更するときは、Containerを削除して新しい設定で作り直すのが一般的です。 :::

フロントエンドのみの環境だと npm だけで賄えるケースも多いですが、バックエンドが絡むと環境の複雑さは一気に増えます。

その複雑さをクリーンに保つために、Docker では「直す」よりゼロから「作り直す」ことを前提にしているのだな、と解釈しました。

レンタルサーバーからCloudflareへ至った理由。その魅力を改めて考える。

Sat, 06 Jun 2026 00:00:00 GMT

レンタルサーバーからCloudflareへ

個人サイトの運用にはレンタルサーバーがとっても便利です。ドメイン管理もメール機能もWordPress自動インストール機能もあります。個人サイト運用者の強い味方ですね。私も昔はレンタルサーバーを使っていました。

ですが、紆余曲折経て、今はCloudflareで個人サイトをホスティングしています。

当初、Nuxt.jsで静的生成 → XサーバーにSFTPでアップロードしていた。（CI/CDに移行したい気持ちが高まっていた）
その後、フレームワークをNext.jsに変更するタイミングでVercelへ移行。ようやくGitからデプロイできるようになった。
ドメインはXサーバーのまま運用していたが、SSL証明書の更新で問題が起き、Cloudflareにドメインを移行。
2024年ごろ、フレームワークをAstroに切り替え、サイトもCloudflare Pagesへ。ようやく一本化できた。

こんな流れで移行していきました。

Xサーバー時代に遭遇したSSL更新のエラーを解消するために、ドメインレジストラの移管先として選んだだけだったCloudflareですが、徐々にその魅力に気づいていきました。

今回は、レンタルサーバーからCloudflareに移行して良かったことについて書きたいと思います。

Cloudflareの良かったこと

フリープランの制限が緩い

フリープランという前提で、Cloudflare、Netlify、Vercelを比較してみます。

Cloudflareはビルド回数・ファイル数・ファイルサイズなどの上限がありますが、いずれも個人Webサイトの範疇なら十分な余裕があります。静的な軽いWebサイトなら帯域幅や転送量は無制限です。

NetlifyはCloudFlareに比べて各制限が強め。Vercelは規約上、商用利用する場合は有料プラン必須となっています。

どんな機能が必要なのか、どう運用するのか、有料プランはどうか、いろいろ検討事項はあるのですが、ひとまずCloudflareは始めやすい、という印象です。

CI/CDがとても簡単だった

CloudflareでGitHubのリポジトリを連携すると、pushするたびに自動でビルド・デプロイされるようになります。かなり簡単にできて驚きました。

ブランチごとに自動でプレビューURLが発行されます。サブドメインとしてdevやstgを設定し、プレビューURLを割り当てると、Stg環境やDev環境を簡単に作れます。その環境にパスワード保護を付ける設定もあります。

SFTPで個別の環境にファイルをアップロードしていた頃のことを思うと、隔世の感があります。

SSLの更新エラーから解放

Xサーバーで管理しているドメインに他のホスティングサービスを割り当てるとSSL証明書の更新時にエラーが発生して更新ができなくなるという事象が発生しました。

具体的に何が原因なのかはわかりませんが、Xサーバー側のインフラの都合だろうと想像はつきます。解決方法を探るよりもCloudflareにドメイン移管してしまう方を選び解決しました。これは間接的な恩恵ですが、一元管理はやはり強いですね。

エッジ配信でサイトが速い

世界中にエッジサーバーがあり、ユーザーの近くのサーバーから配信されます。日本国内なら大阪、東京、福岡、那覇と4箇所。後述で考察を書きますが、CDNとエッジサーバーの組み合わせがCloudflareの大きな魅力だと考えています。

考察: SSG とCDNとエッジ配信

Cloudflareはデフォルト設定ではSSG, SSRを問わずhtmlをキャッシュしないそうです。（画像やJSなどのアセットはキャッシュします）

Default Cache Behavior · Cloudflare Cache (CDN) docs

CloudflareといえばCDNでキャッシュ、というイメージが強いので意外でした。

なぜhtmlをデフォルトでキャッシュしないのか、その理由を考察してみました。観点は2つ。

エッジ配信：ユーザーに地理的に近いサーバーからコンテンツを返す
キャッシュ：一度処理した結果を保存しておき、次のリクエストから使い回す

キャッシュが特に威力を発揮するのは、オリジンサーバーの処理が重い場合です。SSRでDBクエリや外部APIの呼び出しが走るような場合、初回の処理結果をキャッシュしておくことで、2回目以降は処理を丸ごとスキップできます。数百msかかる処理が一瞬になる、という効果です。

ではSSGの場合はどうでしょう。SSGはビルド時にすべてのHTMLを生成します。つまり「サーバーサイドの処理」はありません。キャッシュで省くべき処理が最初から存在しないので、HTMLをキャッシュしてもあまり速度は変わらないのかもしれません。むしろエッジサーバーの数、つまりユーザーに地理的に近い場所に配信サーバーを多く設置することの方が重要なのでは？と思いました。

加えて、キャッシュにはデメリットもあります。コンテンツが更新されたとき、古いキャッシュをいつ・どうやって削除するかの設計や運用を誤ると、ユーザーに古い情報を表示し続けることになります。

CloudflareがデフォルトでHTMLをキャッシュしないのは、こうしたリスクを避けつつ、エッジ配信だけで十分な速度を実現できる、という判断なのだと思います。SSGサイトとは相性が良さそうです。

ちょっと面倒なこと

レンタルサーバーであれば、ドメインに紐づいたメールアドレスを作って運用することができますが、Cloudflareにはメールサーバーやメール管理機能がありません。ここが国内のレンタルサーバーと考え方が違うところですね。

独自ドメインのメールアドレスを使いたい場合は、別途用立てする必要があり、私はさくらのメールとZoho Mailを試しています。

自分で使う分には用途に合ったものを選べばよいのですが、クライアントワークの場合はドメインを移管するか、メールアドレスとサイトを分けて運用するか、なんらか検討が必要です。

Cloudflareへの移行でよかったことまとめ

フリープランの制限が緩い 転送量・ビルド回数など個人サイトには十分な上限で、商用利用もOK
CI/CDがとても簡単 GitHubと連携するだけで自動デプロイできる
Stg/Dev環境を手軽に構築できる プレビューURLをサブドメインに割り当てるだけで環境が作れる
SSLの管理が楽になった ドメインをCloudflareに一元化したことでSSL更新エラーから解放された
エッジ配信でサイトが速い 世界中のエッジサーバーからユーザーに近い場所で配信される

CI/CDに関して言えば、レンタルサーバーでもGitHub ActionsからSSH経由でrsyncするという手がありますが、自前で実装する必要があるので、最初から環境があるCloudflareはやっぱり楽ですね。

AstroなどでSSGで個人サイトを作成しているなら、Cloudflareは有力な選択肢だと思います。

補足

今回の記事ではCloudflare PagesとCloudflare Workersの違いについては触れませんでした。今の段階では私はCloudflare Pagesを使用していますが、ゆくゆくはCloudflare Workersに統合されます。これについてはまた別の記事を書きたいと思います。

Webサイトを作るなら、Astroがかなり良いと思う理由。

Sun, 17 May 2026 00:00:00 GMT

Next.jsでWebサイトを作ったときの違和感

Astroを使い始める前、私はNext.jsでいくつかのWebサイトを実装していました。Next.jsはReactのメタフレームワークとして圧倒的なシェアを持ち、機能も豊富で、技術選定で迷ったらNext.jsを使っておけば問題ない、と考えていました。

ところが実際に「コーポレートサイト」「テキスト主体のページ」「ブログ」といったコンテンツ中心のWebサイトを作ってみると、どうにも噛み合わない感覚が残りました。

構成によっては、ほぼ静的なページでも数百KBのJavaScriptが配信されることがある。API RoutesもMiddlewareもISRも使っていないのに、フレームワーク全体がアプリケーション寄りの機能を前提に設計されているので、静的サイトとして出力するために、デフォルトの機能をオプトアウトする前提で実装する場面がちらほら。

使わない設定を把握するための調査をしているうちに、「そもそもNext.jsを使う意味は何だろう」という気持ちになってきました。

やはりNext.jsはWebアプリケーション寄りのフレームワークで、コンテンツ中心のWebサイトを作るには、ややオーバースペックだと感じるようになりました。

Astroはコンテンツ主導型Webサイトのためのフレームワーク

Webアプリは状態管理・認証・サーバー処理・リアルタイム性など高度なJavaScriptの実装が必要なので、フレームワークの基盤としてJavaScriptありきで設計されます。一方、コンテンツ配信メインのWebサイトはページの表示速度やSEOなどが大切で、JavaScriptは「必要なUI表現が実装できれば十分」という感覚がしっくり来ます。

この違いを真正面から受け止めて設計されているのが、Astroというフレームワークです。

Astroの公式サイトには、The web framework for content-driven websites（コンテンツ主導型ウェブサイトのためのWebフレームワーク）と書かれています。

マーケティングサイト、ドキュメント、ブログ、ポートフォリオ、コーポレートサイト、ECのブランドサイト、これらがAstroの主戦場と言えるでしょう。

では、具体的にAstroにはどんな機能があるのでしょうか？設計思想を交えて、私が気に入っているポイントを順に紹介します。

1. 「JavaScriptを送らない」がデフォルト

Astroの最も特徴的な思想は、デフォルトでクライアントJavaScriptをゼロにすることです。

.astroファイルのフロントマターに書いたJavaScriptは、ビルド時にサーバー側で実行されHTMLに変換されます。クライアントにはHTMLだけが届きます。

2. UIライブラリを自由に選べる

クリックやスクロールで動作する動的なUIはどう実装するか？AstroはReact・Vue・Svelte・Solidなど、お好みのUIライブラリをコンポーネント単位で組み込むことが可能です。

これを支えているのがアイランドアーキテクチャという仕組みです。静的なHTMLという「海」の中に、インタラクティブな「島」が浮かんでいるイメージで、Next.jsのように「ページ全体がReactアプリ」という構造ではなく、「ページはHTMLで、必要な部分だけがUIコンポーネントの島」という構造になっています。

インタラクティブなUI部品が必要になったら、その箇所だけclient:*ディレクティブを付けてオプトインします。

---
import Counter from '../components/Counter.jsx';
---
<Counter client:load />

client:load（即時ハイドレーション）、client:idle（ページの初期読み込みが終わり、ブラウザが待機状態になったとき）、client:visible（ビューポートに入ったら）、client:media（メディアクエリが一致したら）など、どのタイミングでハイドレーションするかまで宣言的に指定できます。

実用上、1サイトで複数のUIライブラリを混ぜることは稀ですが、「自分の好きなUIライブラリを持ち込める」「フレームワークの将来的な乗り換えが楽」という意味で大きな安心感があります。

3. `.astro`テンプレート構文が書きやすい

Astro独自の.astro構文も気に入っているポイントです。

---
// フロントマター（サーバーサイドJS）
import { getCollection } from 'astro:content';
const posts = await getCollection('blog');
---

<ul>
  {posts.map(post => <li>{post.data.title}</li>)}
</ul>

<style>
  /* スコープ付きCSS */
  ul { padding: 0; }
</style>

<script>
  // クライアントサイドJS
  console.log('Hello from the browser');
</script>

ポイントは3つあります。

JSX（TSX）に似た構文で、Next.jsから移行しやすい。{...}の式展開やコンポーネントの書き方はReact経験者なら違和感なく書けます。

HTML・スコープ付きCSS・クライアントサイドJSを1ファイルにまとめられる。VueのSFCやSvelteのように、CSSもJSもページ内に閉じるべき処理をまとめて書けるのが嬉しいですね。

「サーバー側で動くJS」と「クライアントで動くJS」が構文レベルで明確に分かれている。フロントマター(--- で囲まれた部分)に書いたJavaScriptはビルド時に実行され、クライアントには送られないため、配信されるJavaScriptが削減されます。DOMの操作やブラウザイベントに対する処理は<script>タグに書くか、前述のようにUIコンポーネントをclient:*付きで配置します。

テンプレートエンジンとUIライブラリのように、役割を明確に分けている。ここもAstroならではの発想が垣間見えます。

4. Webサイトを作るための機能が揃っている

コンテンツ駆動サイトに特化しているだけあって、Webサイト制作に必要な機能が公式で揃っています。

Content Collections + Content Layer API: ローカルのMarkdown / MDX / JSON / YAMLをZodスキーマで型安全に扱える仕組み。社員紹介ページの一覧やブログ記事のような、CMSを導入するほどではないが構造化したいコンテンツに最適です。
公式のRSS・sitemapパッケージ: 別途ライブラリを探して組む必要がない。
View Transitions: MPAでありながらSPA風の滑らかなページ遷移を後付けできる。
Markdown/MDXでのページ作成: src/pagesに.mdを置けばそのままページになる。

歴史あるNext.jsやNuxt.jsには一歩及ばないかもしれませんが、それでも必要十分なパッケージが揃っている実感があります。Webサイトを作る分には困ることがない、という印象です。

5. ホスティング環境に合わせたアダプタ

アダプタとは、デプロイ先の環境に合わせてAstroの出力を最適化するプラグインです。

Astroは基本的にビルド時に静的HTMLを生成する設計です。生成された成果物は、Cloudflare Pages・Netlify・Vercel・S3 など、静的ホスティングならどこにでも置けます。何なら国産レンタルサーバーも大丈夫！サーバー機能が必要になっても、Node.js・Vercel・Netlify・Cloudflare Workers・Denoなど、アダプタを切り替えればホスティング先を変えられます。

静的HTMLの生成がビルド時に完結する設計なので、ホスティング側の制約を気にせず作れる。これはWebサイト制作で意外と効いてきます。このサイトはホスティング先としてCloudflare Pagesを採用していますが、別環境への移行が必要になっても、コードベースを大きく書き換えずに対応できる安心感があります。

まとめ

紹介した内容はAstroの魅力のほんの一部ですが、伝わったでしょうか？

Next.jsは「Webアプリを作る」ために、多くの強力な機能を内蔵しています。

Astroは「コンテンツ駆動Webサイトを作れる」ことを目指していて、そのために必要なものを揃え、不要なものを削ぎ落とし、Webサイトとしての性能向上や実装体験の良さを追求しています。

それぞれのフレームワークに特長があり、適切な技術選択が必要です。将来的に、Next.jsがパワーアップするかもしれないし、新たなプロダクトが台頭してくるかもしれません。

エンジニアとして、これからもキャッチアップを続けていこうと思います！

Link

::github{repo="withastro/astro"}

Astroのテーマ「Fuwari」の紹介とカスタマイズ

Fri, 08 May 2026 00:00:00 GMT

このサイトはテンプレートテーマ「Fuwari」とフレームワーク「Astro」で作りました。

Astroは、静的（SSG）サイトやコンテンツ中心のWebサイトの作成に適したフレームワークです。魅力的な機能満載で、筆者はサイト制作はもっぱらAstroを使っています。

いつもはデフォルトの状態から作成を始めるのですが、このブログでは既存のテンプレートテーマを使用させていただきました。Fuwariというテーマです。

Fuwariについて

Fuwari デモサイト

かわいいイラスト、角丸で統一されたあしらい、抑えたカラートーンが目を引きますが、それだけではありません。機能開発の側面でも便利な実装が標準装備されていました。

特に良いと思った機能をご紹介します。

ページ遷移アニメーション

ページ遷移時にふわっとしたアニメーションが自動的に適用されます。画面が一瞬で切り替わるのではなく、前のページがフェードアウトし、新しいページがフェードインするような効果が心地よいですね。

この遷移アニメーションは、@swup/astroパッケージを使うことで実装されています。特別な設定なしに使い始められるのが嬉しいポイントです。

MDファイルでページ作成

ブログ記事や固定ページをMarkdown形式で書くことが出来ます。この仕組みは、Astro標準機能のContent Collectionsを利用した実装です。

src/content/posts/ ディレクトリ下にMDファイルを作成し、YAMLフロントマター（タイトルや公開日などのメタデータ）とMarkdown本文を書くだけで公開ページが生成されます。

これも追加実装無しですぐに使えるのがありがたいですね！

サイト内検索

静的サイトなのに検索ができちゃいます。

Pagefindは静的サイト向けの全文検索ライブラリで、データベースを必要とせず、静的ファイルのみで検索機能を実現します。

AstroでビルドしたHTMLから検索インデックスを自動生成します。検索に必要なJavaScriptやインデックスファイルはすべてビルド成果物に含まれるため、CDNやホスティングサービスにそのままデプロイできます。

公式サイトによると、10,000ページ規模のサイトでも検索に必要なネットワーク転送量は300kB以下（多くの場合100kB前後）に抑えられるそうで、パフォーマンス面でも優秀です。

すごいですね〜！

sitemap.xmlとrss.xmlとrobots.txtを自動生成

SEOやブログ読者向けに欠かせない3つのファイルが自動生成されます。

sitemap.xml は@astrojs/sitemapで実装。astro.config.mjsに設定を追記するだけで、ビルド時にサイト内の全ページを収録したsitemap-index.xmlが自動的に出力されます。

rss.xml は@astrojs/rssパッケージを利用したsrc/pages/rss.xml.tsで生成されます。記事タイトル・公開日・説明文、Markdownで書いた本文など、RSSに表示させたいものをカスタマイズできます。

robots.txt はsrc/pages/robots.txt.tsで生成されます。全クローラーに対してAstroの内部ディレクトリ（/_astro/）へのアクセスを禁止と、sitemapのURLの明示がデフォルトで書かれています。

その他

ライト/ダークモード対応
カスタマイズ可能なテーマカラーとヘッダーバナー
ブログ記事の見出しリンク自動生成
ブログのページネーション
アーカイブページはタイムライン構成
RemarkプラグインでMD記法を拡張
Faviconの初期設定

Fuwari未実装の機能を追加

以下、すこしだけ追加で機能実装、設定調整しました。

サイトのURLを.envに記載しastro.config.mjsにimportするように変更。loadEnvを使用。
RSSフィードで生成するサイトのURLをastro.config.mjsから取得するように変更。
canonicalを自動生成する機能を追加。
404ページを追加。
faviconにtype属性を設定できるよう拡張。
投稿内のlicense表示をoffに変更。
rehype-external-links を導入し、MD記法で外部リンクにtarget="_blank"を自動追加するように拡張。
etc

まとめ

Fuwariはかわいい見た目と必要十分な機能が最初から備わっている、完成度の高いテーマだと思いました。特に、作るのが億劫になりがちなsitemap.xmlやrss.xml、robots.txtがデフォルトで生成可能になっているのは良いですね。

Astroでブログを始めたい方にはぜひ試してみてほしいテーマだと思います！

Link

::github{repo="saicaca/fuwari"} ::github{repo="withastro/astro"}

Stella Dev

Container・Image・Volumeから始めるDocker入門

3つのキーワードからDockerを始める

Container, Image, Volume それぞれの役割

Container

Image

Volume

WordPressで学ぶ、Docker環境の構築手順

Step 1 : Container と Image を決める

Step 2 : Volume を設計する

Step 3: docker-compose.yml を書く

Step 4: Containerを起動する

まとめ

余談: Containerはなぜ作ったり削除したりするのか？

レンタルサーバーからCloudflareへ至った理由。その魅力を改めて考える。

レンタルサーバーからCloudflareへ

Cloudflareの良かったこと

フリープランの制限が緩い

CI/CDがとても簡単だった

SSLの更新エラーから解放

エッジ配信でサイトが速い

考察: SSG とCDNとエッジ配信

ちょっと面倒なこと

Cloudflareへの移行でよかったことまとめ

補足

Webサイトを作るなら、Astroがかなり良いと思う理由。

Next.jsでWebサイトを作ったときの違和感

Astroはコンテンツ主導型Webサイトのためのフレームワーク

1. 「JavaScriptを送らない」がデフォルト

2. UIライブラリを自由に選べる

3. .astroテンプレート構文が書きやすい

4. Webサイトを作るための機能が揃っている

5. ホスティング環境に合わせたアダプタ

まとめ

Link

Astroのテーマ「Fuwari」の紹介とカスタマイズ

このサイトはテンプレートテーマ「Fuwari」とフレームワーク「Astro」で作りました。

Fuwariについて

ページ遷移アニメーション

MDファイルでページ作成

サイト内検索

sitemap.xmlとrss.xmlとrobots.txtを自動生成

その他

Fuwari未実装の機能を追加

まとめ

Link

3. `.astro`テンプレート構文が書きやすい