タグ

ブックマーク / future-architect.github.io (6)

  • 2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ

    最近はお客さんとの勉強会でDockerのドキュメントをつまみいして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事Pythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

    2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ
  • 個人的docker composeおすすめtips 9選 | フューチャー技術ブログ

    記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を一部ブラッシュアップしたものになります。 はじめにみなさん、docker composeを利用しているでしょうか? 複数のdockerコンテナをまとめて立ち上げたり、環境変数を定義できたり便利ですよね。 この記事ではある程度docker composeを利用している方向けに私が便利、便利そうと感じたdocker composeの機能を挙げてみました。 docker compose cli v2を利用docker-composeではなく docker composeコマンドも利用可能になっています。 Docker Desktopでは v3.4.0から利用可能で、基的にはコマンドの互換性あります。 ファイル監視による自動更新docker compose 2.20.0からCompose

    個人的docker composeおすすめtips 9選 | フューチャー技術ブログ
  • AGPLを理解する: もっとも誤解されたライセンス | フューチャー技術ブログ

    このエントリーはSayanさんによるUnderstanding the AGPL: The Most Misunderstood Licenseの日語訳になります。 オープンソースの出現は、ソフトウェア産業全体を一変させました。しかし、オープンソースのコードを使って誰が何をできるかを管理することは課題でしたし、今も解決していません。オープンソースライセンスはそこに救いの手を差し伸べました。しかし、常に次のことを忘れないでください:石のない土地はなく、骨のない肉はありません。OSI(オープンソースイニシアチブ: オープンソースを促進することを目的とする組織)が承認したライセンスは80以上あり、その数はさらに増加しています。それぞれのライセンスには利点と欠点があるため、オープンソースの開発者は自分のプロジェクトにあったライセンスを選ぶのは簡単ではありません。Affero General Pu

    AGPLを理解する: もっとも誤解されたライセンス | フューチャー技術ブログ
  • Auth0 導入編 | フューチャー技術ブログ

    始めに様々なシステムを構築する中で必ず発生する要素 ログイン そのログインを支える技術要素 認証・認可 しかし、認証認可の壁は無駄に高く、調べ始めるとまずは数々の専門用語に阻まれ BASIC認証・OAtuh・OpenID・Jwt・Jwk・Jwe… 次に、認証Flowに阻まれます。 Implicit Flow、Client Credentials Flow…etc これらを比較的容易に実装する、Auth0を紹介していきます。 なぜ今回の連載がAuth0なのか?社内で以下の要件を持つ案件が複数あり、結果としてそれぞれでAuth0を採用・知見が溜まったため、連載という形をとることにしました。 OIDC(OpenIdConnect)準拠の要件 Google/Facebookなどのソーシャル連携の要件 開発の期間が短い メンテナンス費用は抑えたい 認証認可の実現方式とAuth0の立ち位置実現方法は大

    Auth0 導入編 | フューチャー技術ブログ
  • サーバーアプリ開発環境(Python/FastAPI) | フューチャー技術ブログ

    Pythonでお仕事する前提で、現在のところで自分が最適と考えるチーム開発のための環境整備についてまとめてみました。今までももろもろ散発的に記事に書いたりしていたのですが、Poetryで環境を作ってみたのと、過去のもろもろの情報がまとまったものが個人的にも欲しかったのでまとめました。前提としては次の通りです。 パッケージ管理や開発環境整備でPoetryを使う 今時はコードフォーマッター、静的チェックは当たり前ですよね? コマンドでテスト実行、コードチェックとか実行とかができる(CI/CD等を考えて) VSCodeでもコマンドで実行しているのと同じコードチェックが可能(ここコンフリクトすると困る) デプロイはDockerイメージ コンテナのデプロイ環境でコンテナに割り当てられたCPU能力を比較的引き出せて、スケールさせたら線形にパフォーマンスアップできるようなasyncioを前提とした環境構

    サーバーアプリ開発環境(Python/FastAPI) | フューチャー技術ブログ
  • 本当に使ってよかったOpenAPI (Swagger) ツール | フューチャー技術ブログ

    サードパーティ製のツール家からは上述のツールが提供されていますが、サードバーティ製の様々なツールが世の中には存在します。 エコシステムが成熟しているのもSwaggerを利用するメリットの1つですね。 https://openapi.tools/ 冒頭のとおり、このサードパーティ製のツールの中で実際に利用して良かったツールを3つご紹介したいと思います。 Stoplight Studiohttps://stoplight.io/studio/ 1つ目のツールは「Stoplight Studio」というAPI仕様を記載するためのGUIエディタとなります。 今までSwagger Editorを利用してYAMLを書いていたそこのみなさん、YAML筋力はもう必要ありません。 Design APIs 10x faster の謳い文句どおり、Stoplight Studioを使えばGUIで直感的に、高速

    本当に使ってよかったOpenAPI (Swagger) ツール | フューチャー技術ブログ
  • 1