並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 1168件

新着順 人気順

HashiCorpの検索結果41 - 80 件 / 1168件

  • HashiCorp、全製品のライセンスを商用利用に制限があるBSLライセンスに変更すると発表

    HashiCorpは今後リリースする全製品のライセンスを、これまで採用してきたMozilla Public License v2.0(MPL2.0)から、商用利用に制限があるBusiness Source License v1.1(BSL1.1)に変更すると発表しました。 Future releases of HashiCorp's core products will adopt the Business Source License. We know our community will have questions, so please read our blog post to understand why, and see our FAQs to understand the changes: https://t.co/riF4EZdQhphttps://t.co/TID1ps7

      HashiCorp、全製品のライセンスを商用利用に制限があるBSLライセンスに変更すると発表
    • Fintechサービスをスピーディーに立ち上げる技術スタック LINEエンジニアに和田卓人さんが聞く TypeScriptとマイクロサービス基盤 - はてなニュース

      多くのユーザーに常用されるコミュニケーションアプリ「LINE」には、エンターテイメントやライフスタイル、ショッピングなど多種多様な関連サービスがあります。 その中でスマホ投資サービス「LINE証券」や、外国為替証拠金(FX)取引の「LINE FX」、個人向けローンサービス「LINEポケットマネー」、「LINE」アプリ上で損害保険に加入できる「LINEほけん」などファイナンシャル(金融)系サービスの展開も拡大しています。 こういったFintech事業に、LINEエンジニアはどう取り組んでいるのか? 「LINE証券」を開発する3名に、事業を支える技術の詳細を伺いました。聞き手は、テスト駆動開発の第一人者でありITコンサルタント・ソフトウェアエンジニアの和田卓人(@t_wada)さん。 信頼性と高速性の両立が求められるFintech領域において、LINEはどのような工夫を行っているのでしょうか。

        Fintechサービスをスピーディーに立ち上げる技術スタック LINEエンジニアに和田卓人さんが聞く TypeScriptとマイクロサービス基盤 - はてなニュース
      • 最近、Terraform のベストプラクティス迷子です - サーバーワークスエンジニアブログ

        技術 1 課の水本です。 最近 Terraform のリファクタリングを行っているのですが、ベストプラクティス迷子になっています。 HashiCorp でも明確な方針は打ち出していない為、Terraform を利用する各プロジェクトで方針を決めているのが現実のようです。 今回は私が出会ってきた問題と、それについての対応、見解を書き連ねていきます。 あくまでも私が思ったことですので、「こうしたほうがいいよ!」というネタも募集しています。 workspace 使うのか使わないのか問題 結論として、私自身は workspace という機能を知ったものの、使うことは考えませんでした。 Terraform では workspace という個別のエリアを設けることが可能で、これを prod や staging と命名し作成しておくと、完全に環境を分離できるというメリットがあります。 ただしデメリットと

          最近、Terraform のベストプラクティス迷子です - サーバーワークスエンジニアブログ
        • ビジネスとオープンソースの狭間で 〜 Embulk の場合 (前編)

          2023 年はビジネスとオープンソースの関係が難しくなった年であったように思います。 6 月には、フルタイムの Ruby コミッターとして研究開発を行っていたお二人がクックパッド社の人員削減の影響を受けたことに端を発して、オープンソースに深く関わってきた一部のソフトウェア・エンジニアを中心に、ビジネスとオープンソースの関係について議論がありました。 8 月には HashiCorp 社が自社のオープンソース製品群のライセンスを Business Source License 1.1 (BSL) に変更したことも話題になりました。 また 2023 年は、一年を通して大規模言語モデル (Large Language Models; LLM) が話題になった年でもあり、ビジネスにも大きな影響がありました。 大規模言語モデルとオープンソースの関係に焦点を絞っても、「非オープンソースのライセンスで公開

            ビジネスとオープンソースの狭間で 〜 Embulk の場合 (前編)
          • Terraformを使って学ぶーAWSにインフラを構築するIaCの基本と、SREが実務で役立つ機能とエコシステムを徹底解説|ハイクラス転職・求人情報サイト AMBI(アンビ)

            ハイクラス求人TOPIT記事一覧Terraformを使って学ぶーAWSにインフラを構築するIaCの基本と、SREが実務で役立つ機能とエコシステムを徹底解説 Terraformを使って学ぶーAWSにインフラを構築するIaCの基本と、SREが実務で役立つ機能とエコシステムを徹底解説 Terraformは、パブリッククラウドのインフラ構築と自動化のツールとして、IaCのデファクトスタンダードとなっています。この記事では、AWS(Amazon Web Services)を活用するハンズオンを通してTerraformの動作を理解し、実務にもとづいて役立つ機能や便利なエコシステム、さらにSRE視点の事例を紹介します。アソビュー株式会社でSREユニットリーダーを務める鈴木剛志さんを中心に6名のメンバーによる共同執筆です。 アイキャッチ画像 アソビューでは、インフラストラクチャーの変更管理にTerrafo

              Terraformを使って学ぶーAWSにインフラを構築するIaCの基本と、SREが実務で役立つ機能とエコシステムを徹底解説|ハイクラス転職・求人情報サイト AMBI(アンビ)
            • Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices | Amazon Web Services

              AWS News Blog Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices Organizations are adopting microservices architectures to build resilient and scalable applications using AWS Lambda. These applications are composed of multiple serverless functions that implement the business logic. Each function is mapped to API endpoints, methods, and resources using s

                Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices | Amazon Web Services
              • Zero Touch Productionとは何か

                GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた.これはインフラの権限管理やインフラの構築そのものの指針となる概念であり,自分がそうあるべきだとずっと思ってきた考え方でもある.これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく. Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている. The SRE organization at Google is working to build upon the concept of least

                • AWS、オープンソースベンダのライセンス変更による商用サービスの制限は「顧客を見ていない」と反論

                  RedisやMongoDB、Kafka、Elasticsearchなどのオープンソースソフトウェアの開発元企業が、AWSなど大手クラウドベンダがそのオープンソースを用いたマネージドサービスを提供して大きな利益を上げていることに反発して、ライセンスを変更するなどで商用サービス化を制限する動きがあることは、今年の1月の記事で紹介しました。 Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発 この動きに対してGoogleは4月、Google Cloudにオープンソースベンダによるマネージドサービスを統合すると発表し、彼らとの戦略的提携という姿勢を打ち出しました。 [速報]Google、大手クラウドに不満を表明していたMongoDB、RedisらOSSベンダと戦略的提携。Google Clou

                    AWS、オープンソースベンダのライセンス変更による商用サービスの制限は「顧客を見ていない」と反論
                  • VSCode拡張機能『Infracost』を使って TerraformテンプレートからAWS利用費を試算してみた | DevelopersIO

                    VSCode拡張機能版Infracostを利用するとTerraformテンプレートを書いているだけで簡易的なAWS利用費の見積もりができます。無料で始められるのでまずはインストールしてみてください。 あしざわです。 皆さんは、これから作成するAWS環境の利用費の見積もり、どうやっていますか? 最近アップロードされたAWS Dev Day 2023 Tokyoのアーカイブ動画を見ていたところ、『Infracost』というIaCテンプレートベースでAM利用費の見積もりができるツールの存在を知りました。 主にTerraformユーザーの方向けになりますが、誰でも無料で始められ導入も簡単かつ便利なツールなのでぜひ皆さんにも使ってほしいと思いブログを書きました。 まとめ InfracostはTerraformテンプレート(.tfファイル)からインフラコストを試算できるツール 無料のInfracost

                      VSCode拡張機能『Infracost』を使って TerraformテンプレートからAWS利用費を試算してみた | DevelopersIO
                    • 「Pulumi」がバージョン1.0に到達、正式版に。インフラの状態をJavaScript、Python、Goなどで記述可能。個人向けサービスは無料で提供

                      「Pulumi」がバージョン1.0に到達、正式版に。インフラの状態をJavaScript、Python、Goなどで記述可能。個人向けサービスは無料で提供 かつてサーバの設定や起動、ネットワークの構成といったインフラの構築は、それぞれの設定ツールやコンソールから運用担当者がマニュアル操作で行ってきました(いまでもそうしている組織は少なくないでしょう)。 しかし仮想化基盤やクラウドなど最近のモダンなインフラでは、APIや設定ファイルを通じてプロビジョニングやコンフィグレーションが可能です。 このようにソフトウェアでインフラの状態の表現が可能になることを、いわゆる「Infrastructure as Code」(コードとしてのインフラ)と呼びます。 Infrastructure as Codeの利点は、インフラの状態をコードで記述することによって、誰でも確実に間違いなく実行できて手作業によるミス

                        「Pulumi」がバージョン1.0に到達、正式版に。インフラの状態をJavaScript、Python、Goなどで記述可能。個人向けサービスは無料で提供
                      • 達人出版会

                        探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う! オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 R/RStudioでやさしく学ぶプログラミングとデータ分析 掌田津耶乃 データサイエンティストのための特徴量エンジニアリング Soledad Galli(著), 松田晃一(訳) 実践力をアップする Pythonによるアルゴリズムの教科書 クジラ飛行机 スッキリわかるサーブレット&JSP入門 第4版 国本 大悟(著), 株式会社フレアリンク(監修) 徹底攻略 基本情報技術者教科書 令和6年度 株式会社わくわくスタディワール

                          達人出版会
                        • Managed Kubernetesサービス開発者の自宅k8sクラスタ全容

                          となっています。 構成図 クラスタを構成するものを図にすると以下のようになります。 この中の一部コンポーネントは次節以降で登場します。 Kubernetes基盤 クラスタの基盤部分についてどのような構成になっているのか説明します。 kubeadm クラスタの構築自体については kubeadm を利用しています。 kubeadm を利用したクラスタの構築方法については公式のドキュメントが参考になります。 Static Pod と systemd kubeadm でデプロイすると kube-apiserver 等は Static Pod で、kubelet は systemd 以下で動作するようになります。 kube-apiserver は意外にメモリを食ってしまうのでそのまま動作させているとメモリ不足になることがあります。(ありました) なので kube-apiserver と etcd の

                            Managed Kubernetesサービス開発者の自宅k8sクラスタ全容
                          • Goの良さを好きなだけ語りたい

                            はじめに サークル内部向けに書いていた記事ですがZennにも供養します。 Tsuzuと申します。早稲田大学のデジタル創作サークルMISWでSysAdとかWeb班長をしています。引退目前の身です。 Goが10周年らしいです。おめでとうございます。 私自身もGoを書き始めて4年半ほどが経過しました。 以前はC++をよく使っていたのですが最近ではWebフロントエンド以外の開発ではGoを利用することがほとんどです。 今回はKibela活性化の目的も含めてGoの良さを思う存分語ろうと思います。 HashiCorpというTerraform、Vaultなどを始めとする様々なGoで開発されたソフトウェアやSaaSを提供している会社があります。 HashiCorpが開発している一般に一番有名なツールはVagrantでしょうか。(VagrantはRubyですが) HashiCorpのCEOであるMitchel

                              Goの良さを好きなだけ語りたい
                            • Terraform で実現する効率的な GitHub 権限管理 - カミナシ エンジニアブログ

                              こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 今月でカミナシに入社してちょうど 1 年が経ちました。前職では 6 年間 SRE チームにいたのでプロダクト開発はブランクがありましたが、さまざまな挑戦をさせてもらっていたらあっという間に 1 年が経っていました。 カミナシのエンジニアリング組織もこの 1 年で急拡大しており、入社当初から比べると正社員のエンジニアも倍以上に増えました。 GitHub の権限管理、どうしていますか? ところで、みなさんが所属されている組織ではどのように GitHub の権限管理を行なっていますか? カミナシではつい先日まで、ほとんどのエンジニアが Organization の Owner 権限を持っていました。理由は、メンターになったエンジニアがニューカマーのユーザーを招待していたからです。 しかし、統制が取れていないことでいく

                                Terraform で実現する効率的な GitHub 権限管理 - カミナシ エンジニアブログ
                              • インシデント指揮官トレーニングの手引き | Yakst

                                [SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1723日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。

                                • 至高のGoプラグイン用ツールを作った - knqyf263's blog

                                  最近YouTuberのリュウジの料理を毎日作っているので至高とか無限とか言いがちですが個人の感想です。万人にとって美味しい料理はないように、万人にとって至高のツールは存在しません(何の話?)。ちなみに公開してすぐバグを見つけてしまったので全然至高じゃありませんでした。 要約 概要 特徴 使い方 流れ 事前準備 インタフェースの定義 SDKの生成 プラグインの実装 ホストの実装 実行 発展 Host Functions ファイルアクセス その他 苦労した点 まとめ 要約 Goでプラグイン機構を実現するためのツールを作りました。Protocol Buffersのスキーマからコードを自動生成するので簡単にプラグイン機構を実現可能です。内部的にはWebAssembly(Wasm)を使っています。最近はWasmはブラウザ外での利活用が進んでおり、今回のツールもブラウザは一切関係ないです。Wasmはサ

                                    至高のGoプラグイン用ツールを作った - knqyf263's blog
                                  • 複数AWSアカウントのインフラを同じコードで Terraform管理するプラクティス - ANDPAD Tech Blog

                                    こんにちは! アンドパッドSREの 宜野座 です。 前回は AWSのアカウント運用改善の取り組みについて記事を書かせていただきました。 今回はアンドパッドでIacへの取り組みとして行っているものの一例として、複数アカウント・複数環境を同一コードでTerraform管理するプラクティスを紹介したいと思います。 少し長くなりますが、お読みいただけると幸いです。 前回ブログ記事 tech.andpad.co.jp なぜIaC(Infrastructure as Code)に取り組んでいるのか Terraformを選んだ理由 同一コードでTerraformを複数アカウント・複数環境へplan, applyしたい terraform init terraform plan terraform apply 環境を増やしたい場合 環境ごとにリソースを作成したり、作成しないようにしたい 他の方法に関して

                                      複数AWSアカウントのインフラを同じコードで Terraform管理するプラクティス - ANDPAD Tech Blog
                                    • 弊社配信基盤を支えるHashiCorp OSS

                                      2019年10月23日「Mitchell Hashimoto in Tokyo! HashiCorp Meetup」にて登壇 https://hashicorp.connpass.com/event/146776/

                                        弊社配信基盤を支えるHashiCorp OSS
                                      • Terraformがノーコードに。HashiCorpが「Terraform Cloud ノーコードプロビジョニング」正式リリース

                                        Terraformがノーコードに。HashiCorpが「Terraform Cloud ノーコードプロビジョニング」正式リリース HashiCorpは、マルチクラウド対応のインフラ構成サービス「Terraform Cloud」をノーコードで設定、実行できる新機能「Terraform Cloud ノーコードプロビジョニング」を正式にリリースしたことを発表しました。 これまでTerraform Cloudでインフラを構成するには、スクリプト言語「HCL」(HashiCorp Configuration Language)を用いて構成を記述する必要がありました。 「Terraform Cloud ノーコードプロビジョニング」では、こうしたプログラミングやTerraformの専門的な知識がなくともインフラを構成することができます。 HashiCorp #Terraform Cloud no-cod

                                          Terraformがノーコードに。HashiCorpが「Terraform Cloud ノーコードプロビジョニング」正式リリース
                                        • AWS CDKとTerraformどちらを使うのが良いのか? - Qiita

                                          今日のお題 結局、CDKとTerraformどっちがいいんだろう、という宗教論争 それぞれをある程度触ってきた上での個人的見解を今後の自分のためにまとめます。 長くダラダラした記事なると思いますがご容赦を。 先に結論 CDK、非常にいいんだけれど、ちょっと辛いかも。 ずっと運用することを考えるとTerraformかな。 (2022/07/22追記) ・・・と思っていたが、使い方によってはCDKの方が良さそうという人になってきました。 その内容は こちら そもそも、CDKとかTerraformってなんだ? 一言で言えば、Infrastructure as Code(IaC)のツールです。 AWSに限らず、GCPやAzureなど様々なクラウドサービスがありますが、これらのクラウドサービス上でコードによりインフラ管理を行う仕組みがIaCです。 これにより、コードさえあれば、どのアカウントにも同じ

                                            AWS CDKとTerraformどちらを使うのが良いのか? - Qiita
                                          • Terraform職人のためのOpenTofu入門 - Qiita

                                            この記事は クラウドワークス Advent Calendar 2023 シリーズ1 の 4日目の記事です。 はじめに 「父さんな、Terraform職人やめてお豆腐職人で食っていこうと思うんだ」と言いたいだけの @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。 このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点のコードベースからforkしたOpenTofuの開発が進められています。 HashiCorpのBSLは、実質的に競合他社の商用利用に制限をかけたもので、ほとんどの一般的なユーザに直接的な追加の制限はありませんが、間接的にTerrafo

                                              Terraform職人のためのOpenTofu入門 - Qiita
                                            • Terraform を使用するためのベスト プラクティス  |  Google Cloud

                                              フィードバックを送信 Terraform を使用するためのベスト プラクティス コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このドキュメントでは、複数のチームメンバーやワーク ストリームで Terraform を使用した効果的な開発を行うためのガイドラインと推奨事項について説明します。 このガイドでは Terraform の概要は説明しません。Google Cloud で Terraform を使用する方法については、Terraform を使ってみるをご覧ください。 スタイルと構造に関する一般的なガイドライン 以下の推奨事項は、Terraform 構成の基本スタイルと構造を対象としています。この推奨事項は、再利用可能な Terraform モジュールとルート構成に適用されます。 標準のモジュール構造に従う Terraform モジュールは、標準のモジュ

                                                Terraform を使用するためのベスト プラクティス  |  Google Cloud
                                              • サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発

                                                2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo

                                                  サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発
                                                • OpenTofuに関する雑感

                                                  2023年12月4日追記。 この記事は2023年の9月下旬に書かれた記事です。 わりと反射的に書いてしまった内容も含んでるので(CNCFのリリースにもコメントを寄越していたGruntworkの関わりを見逃してたのは痛恨のミス。色んな思いがあるのはそれはそう)、本件について語るにもっと最適な方の説明を読んでいただければ幸いです。 先月行われたHashiCorp社によるソフトウェアライセンスの変更はTerraformコミュニティに衝撃を与えたことは記憶に新しい。具体的には、Terraformのライセンスが、オープンソース/フリーソフトウェアを前提としたMPL2.0から、商用利用に制限をかけられたBSLv1.1に変更された。これにより、Terraformは伝統的な意味でのオープンソースソフトウェアではなくなってしまい、ソースコードが単に利用できるソフトウェアに変わってしまったと評する人もいる。[

                                                    OpenTofuに関する雑感
                                                  • Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog

                                                    SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯(ステージング環境を後から立てたり!)から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a

                                                      Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog
                                                    • 元々社員の約9割が在宅勤務の「リモートファースト」企業HashiCorp、創業者のハシモト氏が語った教訓

                                                      元々社員の約9割が在宅勤務の「リモートファースト」企業HashiCorp、創業者のハシモト氏が語った教訓:リモートワークとは、「家を職場にすること」ではない(1/2 ページ) オープンソースのITインフラ構築自動化ツール群を事業とするHashiCorpは、創業当初から「リモートファースト」を続けてきた。創業者のミッチェル・ハシモト氏が、コミュニケーションの大切さとパーソナルヘルスについて、具体的な教訓を語った。

                                                        元々社員の約9割が在宅勤務の「リモートファースト」企業HashiCorp、創業者のハシモト氏が語った教訓
                                                      • Vagrantが開発言語をRubyからGo言語へ切り替え、次のメジャーバージョンアップ「Vagrant 3.0」で。現バージョンとの互換性は維持

                                                        Vagrantが開発言語をRubyからGo言語へ切り替え、次のメジャーバージョンアップ「Vagrant 3.0」で。現バージョンとの互換性は維持 HashiCorpは、仮想環境をプログラミングできるツール「Vagrant」の開発言語を、これまでのRubyからGo言語切り替えることを明らかにしました。 Learn more about the new features, capabilities, and improvements we’re making on our journey toward Vagrant 3.0. https://t.co/49scP0FdqW — HashiCorp (@HashiCorp) June 11, 2021 時期未定ながら、今後約1年のあいだに登場するVagrant 2.3、Vagrant 2.4を経て、Vagrant 3.0でGo言語への移行が完了

                                                          Vagrantが開発言語をRubyからGo言語へ切り替え、次のメジャーバージョンアップ「Vagrant 3.0」で。現バージョンとの互換性は維持
                                                        • HashiCorp、UIデザインシステム「Helios」をオープンソースで公開。UIコンポーネントやアイコンなど

                                                          HashiCorp、UIデザインシステム「Helios」をオープンソースで公開。UIコンポーネントやアイコンなど TerraformやVagrantなどで知られるHashiCorpは、同社製品のユーザーインターフェイス開発に使われているデザインシステム「Helios」をオープンソースで公開しました。 デザイン設計の原則やサンプルと共に、25種類のUIコンポーネントと数百のアイコンが含まれています。 Check out the #opensource launch of Helios, the Ember.js-based design system we use to design and build our better, more consistent product UIs. https://t.co/1KqpdTMIri — HashiCorp (@HashiCorp) Janua

                                                            HashiCorp、UIデザインシステム「Helios」をオープンソースで公開。UIコンポーネントやアイコンなど
                                                          • SREエンジニアが組織改善プロジェクトを立ち上げてみた - ぐるなびをちょっと良くするエンジニアブログ

                                                            こんにちは。データ・AI戦略部 SREチームの小野です。普段は部内のシステムに対し、SRE推進活動を行っています。直近では、データエンジニアと協力してデータ基盤周りの改善に取り組んでいます。 <SREの主な仕事> IaC化(Terraform/Terraform Cloud Business)の導入・推進 SLI/SLOの導入・推進 ポストモーテムの導入・推進 アプリケーションデプロイ基盤の導入・推進 ツールやAPIの設計・開発 インフラ設計・開発・運用 トイル削除・システムの自動化 データ基盤改善 一般的なSREエンジニアは、インフラ関連の業務が中心になると思います。しかし、データ・AI戦略部のSREチームは、開発を含めた幅広い仕事をします。やりたいことがあり、手をあげればそれを後押ししてくれる雰囲気の職場です。 今回は、SREエンジニアである私が、組織改善プロジェクトを立ち上げた話をお

                                                              SREエンジニアが組織改善プロジェクトを立ち上げてみた - ぐるなびをちょっと良くするエンジニアブログ
                                                            • Mirrativ のバックエンドで使っているGoライブラリを紹介する! - Mirrativ Tech Blog

                                                              こんにちは、バックエンドエンジニアの夏(なつ)です。今回はMirrativのバックエンドで使っているライブラリをご紹介します。 これらの記事のバックエンド版になります!(2年越し) tech.mirrativ.stream tech.mirrativ.stream ライブラリ一覧 https://pkg.go.dev/ オリジナルの The Go gopher(Gopherくん) は Renée French によるデザイン cloud.google.com/go/bigquery 分析チームが生成したユーザの特徴量などがBigQuery上に存在しているため、それらをバッチ処理でMySQL上に取得する際に利用しています。 tech.mirrativ.stream cloud.google.com/go/compute/metadata 開発環境などでしか動いてほしくない処理が本番環境上で動

                                                                Mirrativ のバックエンドで使っているGoライブラリを紹介する! - Mirrativ Tech Blog
                                                              • Terraform を管理するリポジトリのディレクトリ構成とその思想 - Mobile Factory Tech Blog

                                                                こんにちは。ブロックチェーンチームのソフトウェアエンジニアの id:odan3240 です。 tech.mobilefactory.jp 上記の記事で紹介した通りユニマ/ガレージのインフラは Terraform で管理されています。 この記事では Terraform を管理するリポジトリのディレクトリ構成とその思想について紹介します。 前提 Terraform を管理するリポジトリは2020年の1月頃に開発されたものです。 当時の最新版の Terraform のバージョンは 0.12 でした。 当時の Terraform のバージョンでのディレクトリ構成の紹介であり、現在の最新版のベストプラクティスに沿わない可能性があります。 ディレクトリ構成 リポジトリルートのディレクトリ構造は次の通りです。以降で紹介するディレクトリ構造は説明のために一部簡略化しています。 $ tree -L 1 .

                                                                  Terraform を管理するリポジトリのディレクトリ構成とその思想 - Mobile Factory Tech Blog
                                                                • Business Source License 1.1

                                                                  HashiCorp が OSI オープンソース・ライセンス のソフトウェア (以降 OSS) 製品を Mozilla Public License 2.0 (以降 MPL) から Business Source License 1.1 (以降 BUSL) にライセンス変更して話題になっています。 自社は主力製品はクローズドソース、それ以外は Apache License 2.0 で OSS として公開という戦略をとっていることもあり、 BUSL について自分の考えを雑に書いておこうと思います。 法律の専門家ではないので、間違いもあると思います。きっちり理解したい人は弁護士に相談しましょう。

                                                                  • Terraformのフォークが「OpenTofu」としてLinux Foundation傘下で正式ローンチ。OpenTFから改名

                                                                    Linux Foundationは、HashiCorpのインフラ構成ツールであるTerraformをフォークしたプロジェクト「OpenTofu」のローンチを発表しました。 We are excited to announce the launch of OpenTofu, an open source alternative to Terraform's widely used infrastructure as code provisioning tool. Read the announcement:https://t.co/Ju0d6Fq190#opensource #opentofu #ossummit pic.twitter.com/gQLGO7iAdu — The Linux Foundation (@linuxfoundation) September 20, 2023 Op

                                                                      Terraformのフォークが「OpenTofu」としてLinux Foundation傘下で正式ローンチ。OpenTFから改名
                                                                    • Terraform で AWS に DB を構築するとき manage_master_user_password を使っていますか? - 電通総研 テックブログ

                                                                      こんにちは。X(クロス)イノベーション本部 ソフトウェアデザインセンター セキュリティグループの耿です。 Terraform で Amazon RDS インスタンス/クラスターを作る時に、password または master_password 属性に指定したマスターユーザーのパスワードが tfstate ファイルに平文で残ってしまう問題がありました。 (参考) https://speakerdeck.com/harukasakihara/sekiyuanaterraformfalseshi-ifang-ji-mi-qing-bao-wokodonihan-mezuhuan-jing-gou-zhu-surunihadousitaraiifalse しかしこれも過去の話。Terraform AWS Provider v4.61.0 からこの問題を解消する方法が提供されているので、それについ

                                                                        Terraform で AWS に DB を構築するとき manage_master_user_password を使っていますか? - 電通総研 テックブログ
                                                                      • Terraformのセキュリティ静的解析 tfsec の導入から始めるAWSセキュリティプラクティス - BASEプロダクトチームブログ

                                                                        こんにちは。BASE BANK 株式会社 Dev Division にて、 Software Developer をしている東口(@hgsgtk)です。 BASE BANK Dev での開発では、クラウドインフラの構成管理に、 Terraform を利用しています。 世の情報をたくさんキュレーションしている CTO の@dmnlkさんに、手軽に CI に組み込めそうなセキュリティチェックツールがあることを教えてもらったので、導入してみました。 CTO氏のキュレーションメディアで紹介された tfsec を早速試して良さそうだったhttps://t.co/bl67dlW2Ub https://t.co/vAkTOVagec— Kazuki Higashiguchi (@hgsgtk) August 21, 2020 このブログの公開日は 2020/10/30 ですので、導入してから約 2 ヶ月

                                                                          Terraformのセキュリティ静的解析 tfsec の導入から始めるAWSセキュリティプラクティス - BASEプロダクトチームブログ
                                                                        • Terraformのライセンスの変更とその影響

                                                                          はじめに 先日、HashiCorp社はの発表により、すべての製品といくつかのライブラリの将来のリリースについて、Mozilla Public License v2.0(MPL 2.0)からBusiness Source License(BSL、またはBUSL)v1.1への移行するがわかりました。 ただし、HashiCorpのAPI、SDK、およびほとんどの他のライブラリはMPL 2.0のままです。 BSLとは? MPL 2.0との違いは? BSLは下記のようにいくつの特徴があります: 特定の期間(通常は数年)の後に、完全なオープンソースライセンス(たとえば、Apache 2.0)に変わるライセンスである。 BSLの下でリリースされたソフトウェアは、特定の期間中は商業的に利用することが制限される。 開発者がソフトウェアの商業的価値を保護しつつ、将来的にはコミュニティに還元することを目的として

                                                                            Terraformのライセンスの変更とその影響
                                                                          • メドピアのECSデプロイ方法の変遷 - メドピア開発者ブログ

                                                                            CTO室SREの侘美です。好きなLinuxディストリビューションはLinux Mintです。 メドピアでは現在多数のサービスを運用しており、そのほとんどがAmazon ECSを構成の中核として利用しています。 ECSに対してデプロイを行う方法としては、CodeDeploy、CodePipeline、Copilot(ecs-cli)等があり、CloudFormationやTerraform等のIaCツールで何をどこまで管理するかも合わせて検討する必要があります。 どの方法にもメリット・デメリットがあり、Twitterや技術ブログを観測している範囲ではデファクトスタンダードと呼べる方法は未だに無いように思われます。 メドピアで最初にECSを利用し始めたのは2018年ころであり、これまで試行錯誤しながらECSのデプロイ方法とタスク定義の管理方法を模索してきました。 今回はメドピア社内で試してきた

                                                                              メドピアのECSデプロイ方法の変遷 - メドピア開発者ブログ
                                                                            • Raft + Redis な内製Redisサーバの紹介 - Mirrativ Tech Blog

                                                                              こんにちは ハタ です。 Mirrativのインフラ内で実際に開発・運用している内製のRedisサーバについてお話したいなと思っています。 前回の記事 は、今回紹介する内製Redisサーバで起きたメモリリーク対策に関するお話しとなっておりますので、もし未読であればあわせて読んでいただければと思います。 今回はなぜ Redis サーバを内製することにしたのかの経緯や実装についての簡単な紹介が出来たらなと思っています Redis 導入の経緯 課題感: 揮発しないでほしい 課題感: 生存時間が短いデータを保持したい 課題感: 日次データをなんとかしたい 候補 Redis Cluster のヨシアシ: slot 管理 Dynomite のヨシアシ: sharding/replication radisha = Raft + Redis + HA Raft クラスタ コマンドとデータストア レプリケ

                                                                                Raft + Redis な内製Redisサーバの紹介 - Mirrativ Tech Blog
                                                                              • Terraformのループ記法を基礎から学ぶ | 外道父の匠

                                                                                Terraform のコーディングにおいて、似た構成の複製をどのように表現するかは結構重要な課題です。放っておくと汚いコピペだらけになっていくからです。 色々な目的とやり方があると思いますので、その表現を実現するためのパーツにでもなればと思い、学習用教材的に書いてみるやつでございます。 目次 説明はそんなに多くないですが、コードのせいで縦長になったので目次を置いておきます。Terraform バージョンは v1.5.7 で動作確認しています。 単体の複製 count for_each セットの複製 module count + module 条件分岐 三項演算子 入れ子 ループ構造 for 複製の方法 階層構造 Pythonの入れ子ループ Terraform の入れ子ループ 続・階層構造 単体の複製 あるリソースに対して、単体の場合は count や for_each を使うことで、lis

                                                                                  Terraformのループ記法を基礎から学ぶ | 外道父の匠
                                                                                • Terraform import のススメ 〜開発効率化編〜 - LayerX エンジニアブログ

                                                                                  こんにちは、LayerX で主にインフラを担当している高江です。 今回は、一見地味ではありますが実はとても役に立つ機能である Terraform import についてお話したいと思います。 Terraform import とは 公式サイトでは次のように説明されています。 Terraform is able to import existing infrastructure. This allows you take resources you've created by some other means and bring it under Terraform management. 要するに、AWS 等のサービスプロバイダー上に既に存在する、Terraform 管理されていないリソースの情報を取得して Terraform 管理下に置く(tfstate ファイルに import する)

                                                                                    Terraform import のススメ 〜開発効率化編〜 - LayerX エンジニアブログ