タグ

2022年11月14日のブックマーク (5件)

  • Dockerコンテナから外部のAPIを叩きたい|fumi

    はじめにDockerを使う時コンテナ間で通信をしたいと言えばdocker-composeで一つのサービスとして囲まれたコンテナ同士の通信のことが多いと思います。このような形ですね。 しかしあるコンテナが全く別の外部コンテナを叩きたい時はどのようにすれば良いでしょうか?このように下のコンテナ同士で通信を行いたい場合ですね。 結論から結論としてはdocker.host.internalでアクセスすることができます。例えば↑の図の左下が5000番ポート、右下が3000番ポートとします。この時 http://host.docker.internal:5000と記述することでアクセスすることができます。 pingコマンドを打ってみると実際に通信できていることが確認できると思います!

    Dockerコンテナから外部のAPIを叩きたい|fumi
  • 伝わる文章 | 基本要素 | SmartHR Design System

    相手に誠実に、わかりやすい文章を書くための心がけをまとめました。 どういう思考プロセスからどんな表現が生まれるのか、参考として実例を紹介しています。実際に読み比べ、SmartHRの従業員として何かを伝えようとするときの、参考にしてください。 伝わる文章のガイドライン何を伝えるかによって、必要な情報の量や説明の粒度は異なります。 情報が不足していたり、逆に情報が多すぎたりすると、読者が意図を読み取れないことがあります。 読み手となる相手の状況(読む場面、事前知識など)を踏まえ、言葉にする内容や表現を厳選することが大切です。 目的に合わせて情報を取捨選択する読者の目線に立ち、コンテンツの目的に合わせて情報を取捨選択しましょう。 実例1:法律や業務に関わる記事目的業務に関係する「厚生年金保険」について正確に知りたいと思っている人に、わかりやすく内容を伝える。 Before日の年金制度は、全国民

    伝わる文章 | 基本要素 | SmartHR Design System
  • Amazon AppFlow 入門として Slack から S3 へデータをロードするフローを作ってみた | DevelopersIO

    とりあえず AppFlow を触ってみたい コンバンハ、千葉(幸)です。 Amazon AppFlow はコーディング不要で SaaS アプリケーションや AWS サービス間のデータ転送を実現するマネージドなインテグレーションサービスです。 今まで触ったことがなかったので、いっちょ入門してみるかということで一番とっつきやすそうな Slack → S3 のフローを作ってみることにしました。 以下に載っている内容をベースに、個人的につまずきが多かった Slack 周りの設定を厚めに取り上げていきます。 Amazon AppFlowでSlackのメッセージをS3に保存する | DevelopersIO Amazon AppFlow を使用して Slack から Amazon S3 にデータをロードする 今回作成する AppFlow の構成 イメージ図はこちらです。 最終的には AppFlow で

    Amazon AppFlow 入門として Slack から S3 へデータをロードするフローを作ってみた | DevelopersIO
  • NAT インスタンス用の AMI を Packer で作ってみた | DevelopersIO

    コンバンハ、千葉(幸)です。 先日、NAT インスタンスを Amazon Linux2 AMI から手作りしてみました。 久しぶりに OS 上でコマンドを叩いてテンションが上がったので、これまた久しぶりに Packer を使ってみるか、ということでパカることにしました。 今回やること 大まかに書くと以下の通りです。 Packer により NAT インスタンス用 AMI をビルド NAT インスタンスのセットアップ クライアントインスタンスから疎通確認 NAT インスタンスを配置する VPC やクライアントインスタンスはあらかじめ作成済みの前提とします。 1. Packer によるビルド 今回使用する Packer は以下バージョンです。 % packer --version 1.8.4 あらかじめ、必要な権限を有する IAM ユーザーのクレデンシャルを AWS CLI プロファイルに設定し

    NAT インスタンス用の AMI を Packer で作ってみた | DevelopersIO
  • 令和なのに NAT インスタンスを手作りして使ってみた | DevelopersIO

    (※)データ処理は 100 GB の前提で計算していますが、戻りの通信も課金対象であるため実際にはもっと増えるはずです。 NAT Gateway は利用期間に応じた単価が高いのと、データ処理量に応じた料金が発生します。NAT インスタンスは、使わない時間は停止することでオンデマンド料金をさらに減らせます。 大抵の場合、NAT インスタンスの方がコストは安くつきます。 このコストの差を鑑みてもなお 番環境では NAT Gateway の採用をお勧めします。 NAT Gateway がマネージドでやってくれる部分や性能のメリットの方が大きいと考えるためです。検証環境や、万が一インターネットへのアウトバウンドが途切れてもクリティカルなことにはならない、というワークロードであればコスト抑制をモチベーションに NAT インスタンスを採用するのもアリだと思います。 それぞれの料金の以下をご参照くださ

    令和なのに NAT インスタンスを手作りして使ってみた | DevelopersIO