Gianni Truzzi

The Latest From Gianni Truzzi

• Cloud Nimble：マルチクラウドおよびハイブリッドDevOpsの次なる進化

  1月 5, 2022 | < 1 min read

  ここ数年、システムアーキテクトは、システムがクラウドネイティブ型であり、アプリケーションが拡張性の高いクラウド基盤向けに最適化されていることが求められています。 今日の環境では、ソリューションがクラウド敏捷性(cloud nimble)を備えているかどうかを問われています。 現代の企業にとって、クラウドコンピューティングは今や、アプリケーション、ストレージ、コンピューティングのための一般的なモデルとなっています。プロバイダーやサービスの範囲が拡大するにつれて、企業はクラウドがビジネスの近代化の鍵であることを認識するようになっています。 大手企業がクラウドコンピューティングを用いてビジネス変革を進化させるにつれて、イノベーションを加速し、クラス最高の状態を維持し、ベンダーロックインのリスクを軽減するために、ハイブリッドおよびマルチクラウドアーキテクチャへの依存度が高まっています。 ここで明らかになったことは、クラウドネイティブ型のソリューションは、クラウド環境やハイブリッド環境においてアジャイルでスケーラブルな運用を行うための出発点に過ぎなかったということです。先進的なDevOpsエンジニアは、クラウド敏捷性を備えているソリューションを模索する必要もあります。パブリックとプライベートの両方の複数のドメインから重要なワークロードを選び、分散させることができる、運用する上で一貫したプラットフォームが必要になります。 ハイブリッドクラウドとマルチクラウドの台頭 組織は、クラウドを使用してイノベーションを迅速に進め、柔軟に拡張しながら、最小限のコストとリスクで大胆なデジタル投資を行うことの利点を認識しています。現代の企業は、今ではクラウド対応、ソフトウェア主導、そして仮想型になっています。 2021年、83%の企業ではクラウドへの支出が120万ドルを超えたと報告され、そのうちの36%は1,200万ドル以上にのぼっています。 このモダナイゼーションが進むにつれて、重要なワークロードを単一のクラウドプロバイダーに任せることにはリスクが伴うことが、これらの組織にとって明らかになってきています。 2021年に29業種の7,000社以上を対象に行われた調査では、単一のプライベートまたはパブリッククラウドを使用していると回答した企業はわずか3%で、2年前の29%から減少しています。回答者の59%は、プライベートクラウドとパブリッククラウドをハイブリッドに組み合わせて使用していると言っています（IBM、Cloud’s Next Leap、2021）。 これらの調査回答者のほぼ5分の4が、ベンダーロックインなしにワークロードを完全に移行可能にできることが、デジタルトランスフォーメーションを達成する上で極めて重要であると述べています。 ハイブリッドクラウドとマルチクラウドは急速に、クラウドサービスを提供するための最も一般的なITアーキテクチャになりつつあります。企業は、単一のクラウドプロバイダーからの切り替えを通じて、仮想運用の俊敏性をさらに高めようとしています。 クラウド敏捷性を備えた企業 この先の企業におけるクラウドコンピューティングは、運用をクラウドネイティブにするだけでは不十分であり、クラウド敏捷性を備えていることが重要です。  クラウド敏捷性を備えた企業は、あらゆるクラウドで、どこでも実行できる機能を求められ、具体的に、以下のようなものが挙げられます。 特定のタスクに対して、クラス最高のサービスを行うための最適なクラウドを選択できる ワークロードに対して、最もコストの低いプロバイダーを割り当てできる 負荷分散または需要価格への調整のためにワークロードをシフトできる データとコンピューティングサービスを地理的に近接させておく 冗長性を確保して99.999%の可用性を維持できる ハイブリッド戦略を採用して、セキュリティや規制の要件に準拠する クラウド敏捷性を備えた企業の方が、バランスやスピードを失うことなく変化に適応することができます。 JFrog DevOps Platformは、DevOpsの成功のためのバイナリ駆動型の方式を可能にする、市場をリードするソリューションのセットです。今日の企業のクラウド敏捷性の要件を満たし、オンプレミス、クラウド、ハイブリッド環境にわたって完全な柔軟性と運用の一貫性を実現します。 一貫した運用モデル 多くの場合、アプリケーションのセルフマネージドなバージョンとそのSaaSオファリングの間には、大きな機能差が存在することがあります。すべての環境間で完全に同等の機能を備えていないバージョンとなっている場合、DevOpsの一貫したモデルを維持する上で大きな障害になる可能性があります。 クラウドネイティブなJFrog Platformは、すべての運用環境で市場をリードする完全な機能セットを提供し、DevOpsの成功に向けて同じベストプラクティスでクラウド間でSDLCを運用することを可能にします。 クラス最高のサービス間での分散 あるクラウドが最適なストレージサービスやセキュリティを提供する一方で、別のクラウドが最高品質のVCSや自動化を提供することもあります。異なるコンピューティング言語やランタイムを対象とするチームは、独自のクラウドベースの開発ツールセットを選択することを好むかもしれません。遅延の影響を受けやすいアプリケーションで高速にアクセスするために、それぞれが独自のクラウドサービス内の局所性を必要とする場合もあります。 クラウド敏捷性を備えたJFrog Platformにより、SRE(Site Reliability Engineer)は、SDLCのさまざまなセグメントに最適なクラウドプロバイダーを選択したり、多様なチームの特定のニーズを満たすことができ、安全で単一の信頼の輪の中でパッケージとバイナリのガバナンスを維持できます。 一貫したセキュリティ体制を維持する クラウドベースのプラットフォーム、ツール、およびサービスといった、さまざまなエコシステムを用いて運用する際、それぞれが独自の保護を備えているため、ソフトウェア開発ライフサイクル（SDLC）全体を通じて一貫したセキュリティ体制を維持することが難しくなってきています。 JFrog Artifactoryのきめ細かなアクセス許可と、複数のプロトコルを介したシングルサインオンとの統合により、組織は複数のクラウドドメインにわたって、ソフトウェアサプライチェーンを一貫した高品質な状態で保護し続けることができます。JFrog Xrayを使用すると、すべてのクラウド環境に対する一貫した監視、レポーティング、脆弱性に対する修正、コンプライアンスに関するスキャンを行うことができます。 SaaS用にクラウドを選択 クラウドの選択肢が1つしかない場合、マルチクラウドSaaS戦略を採用することはできません。 JFrogのクラウド敏捷性を持つソリューションは、選択性と透明性の両方を兼ね備えています。JFrog Platformのアカウントは、3つの主要なクラウドプロバイダー（AWS、Google Cloud Platform、Azure）のいずれかまたはそれぞれで自由にホストできるため、チームが使用するクラウドエコシステムツールとデータの近接性を確保できます。 課金を簡単にするため、クラウドプロバイダーのマーケットプレイスを通じてJFrogアカウントを作成し、既存のクラウドクレジットによって月々のサブスクリプションを支払うことができます。 マルチドメインの自動化 企業はJFrog APIを使用することで、バイナリを安全に配信したり、あるクラウド環境から別のクラウド環境にペイロードを開放したり、JFrog Platformのデプロイ間でSDLCを相互運用したりできます。 リポジトリのレプリケーションにより、チームはドメイン、リージョン、プロバイダー間でアーティファクトとビルドを共有できると同時に、各チームのデータの局所性を維持して、共通のDevOpsプラクティスのセットをフルスピードで運用できます。…

  さらに見る
• 使用されている脆弱な Log4j を捕まえろ：検知、修正、防御

  12月 27, 2021 | < 1 min read

  多くの組織において、広く使用されている Log4Shell というオープンソースソフトウェアに、長期に渡ってクリティカルな脆弱性が存在していたという驚きの発見は、まるでスクルージとグリンチ※が手を組んで、最大のホリデー強盗を行ったかのようなものでした。世界中のインシデント レスポンス チームは、数百万とは言わないまでも、数千のアプリケーションを修復するために奔走しています（※訳注：それぞれ英・米の小説・絵本の主人公。クリスマス嫌いで広く知られるのでこのシーズンを意識した表現。「ケチ」の意味で用いられることが多い） 元ホワイトハウスCIOで、現在 Fortalice Solutions の CEO を務める Theresa Payton 氏は、「サイバー犯罪者にとって、これは一足早いクリスマスだ」と説明しています。攻撃者はすぐにこの脆弱性をエクスプロイトして、暗号通貨マイニングマルウェアをインストールしたり、認証情報を盗んだりしたのです。 この危機に対応するために、関連チームは週末を失い、パーティーを欠席し、旅行プランもキャンセルして、膨大な開発環境という干し草の中からの針探しを余儀なくされました。 しかし、Artifactory と Xray のユーザは、このような状態にならなくて済んでいます。もしあなたがその一人なら、JFrog DevOps Platformをミッションクリティカルなソフトウェア開発ライフサイクル（SDLC）プロセスの中心に据えることで得られる長期的なメリットを、直接体験することができるでしょう。 Artifactory のバイナリ リポジトリ管理下に蓄積されたパッケージ、バイナリ、イメージ、メタデータにより、Apache log4j の脆弱性、または、その他のセキュリティ問題に対して迅速に修正するために必要なものはすでに揃っています。 JFrog Platform を使用して、どのように組織を迅速に保護できるかを説明します。 検出 - Artifactory の build-info メタデータと Xray の深い再帰的スキャンを使用して、本稼働しているアプリケーションのインベントリ全体にわたって、推移的依存関係を含む log4j パッケージのすべての存在を検出できる 修正 - Xray による脆弱な log4j パッケージを使用するアプリケーションの特定後、開発者は、更新された安全なバージョンを使用するようにソースコードを更新し、新しいビルドを作成することができる 防御 - Xray スキャン結果に基づいて、log4j の脆弱なバージョンを使用するビルドや、パイプラインにある log4j 脆弱性を持つビルドのリリースへの昇格をブロックできる SBOM にある Log4j の全てを検出…

  さらに見る
• アーティファクト・ジャングル、開発との接点を探る

  8月 16, 2021 | < 1 min read

  開発者である私たちはどのように設計し、コーディングし、デバッグし、結合するかにほとんどの時間を費やしています。思考はソースファイルに向けられ、バージョンコントロールシステムを構成するリポジトリやブランチに注目します。それが私たちの仕事であり、私たちの世界なのです。 しかし、DevOpsのプロフェッショナルになるためには、コードを実行する環境に持っていくために何が起こるかを考えなければなりません。DevOpsとはアプリケーションの開発から配布までを行うことです。 DevOpsを成功させるためには、ソフトウェアの構成要素であるアーティファクトに焦点を当てなければなりません。 配布されるアプリケーションはバイナリ、依存関係、イメージなどのアーティファクトで構成されており、それらは互いに接続されています。納品可能なソフトウェアアプリケーションを作るために必要なアーティファクトの多様なエコシステムを理解することは本番環境へのリリースを加速するための第一歩です。 アーティファクトのエコシステム 自然界では全ての生物と物理的環境が相互に影響し合って生態系を構成しています。それぞれがバランスを保ちながら他方を支えています。 継続的インテグレーション・パイプラインにおけるアーティファクトのエコシステムも、ほぼ同じです。アーティファクトは他のアーティファクトに依存し、あるプロセスで作られたアーティファクトは別のプロセス利用されます。 アーティファクトのエコシステム パッケージ アプリケーションはMaven、npm、PyPi、Conanなどのパッケージ管理技術によって配布されるオープンソースやプロプライエタリの依存関係に依存しています。これらのコンポーネントは直接依存と他動的依存間でアプリケーションコードの大部分を構成します。 ビルド デプロイ可能なアプリケーションはソースコード、依存関係、サポートファイルからビルドされ、WAR、ZIPまたはその他のアーカイブ形式になります。Artifactoryは「ビルド情報」メタデータによってビルドを記録し、すべてのコンポーネントを元に戻すことができます。 コンテナ アプリケーションをDockerやOCIイメージとしてパッケージ化してコンテナとして使用したり、Artifactoryのプライベートレジストリに保存したりすることができます。 設定ファイル アプリケーションにはKubernetesでオーケストレーションを行うためのHelmのような設定ファイルやChefやPuppetのようなInfrastructure-as-Codeファイルが必要になります。Artifactoryはこれらのリポジトリタイプをネイティブにサポートしているため、これらの重要なファイルを信頼できる唯一の情報源に保管することができます。 リリース 最新のアプリケーションは通常、相互に動作するマイクロサービスで構成されており、バージョン管理された一式を配布する必要があります。JFrog Distributionはアプリケーションのコンポーネントを署名付きのリリースバンドルにまとめ、トレースしているため、エッジサーバーに安全に配布することができます。 Artifactoryの信頼できる唯一の情報源 Artifactoryは全てのアーティファクトのためのユニバーサルリポジトリマネージャであり、多様なアーティファクトエコシステムのための信頼できる唯一の情報源を提供します。 約30種類のパッケージタイプをネイティブにサポート（Genericリポジトリを含む）しており、開発組織のアーティファクトエコシステム全体を保存、整理、追跡するための唯一の情報源となります。開発者は日常的に使用しているパッケージ管理サービスを利用し、パッケージやイメージをArtifactoryリポジトリに保存・取得することができます。 Artifactoryリポジトリタイプ Artifactoryのユニバーサルなバイナリ管理は組織内のすべての開発者に提供されます。Java、JavaScript、Python、Go、C++、C#、Swift、Rustなどでプログラムを開発しているかどうかにかかわらず、Artifactoryはすべてのパッケージとビルドの中心となります。 メタデータ Artifactoryはパッケージタイプや「ビルド情報」と呼ばれるメタデータを保持しているため、アーティファクトがどこから来たのか、どのように作成されたのか、どこに配置されたのかを知ることができます。この包括的なメタデータがあれば全てのアーティファクトがどこから来たのか、またどこで使用されたのかを追跡できます。 リモートリポジトリのプロキシ Artifactoryのリモートリポジトリは唯一の情報源にリモートリソースの依存関係をキャッシュするをローカルプロキシです。開発者はリモートリソースに直接アクセスすることなく、Artifactoryの依存関係を不変的なコピーをオンデマンドで使用してビルドします。 これにより、物理的な距離や不安定なサービス接続に起因するネットワークの遅延を解消し、ビルドを可能な限り高速に実行することができます。また、プロキシは接続の中断やリモートサイト自体が利用できなくなった場合の問題を防ぎます。 開発からDevOpsへ アーティファクトのエコシステムを理解し、継続的統合パイプラインでのフローを管理する方法を理解することは、開発からDevOpsへの移行の第一歩です。 すべてのアーティファクトがArtifactoryの唯一の情報源によって管理されていれば、企業全体が同じSDLCワークフローとベストプラクティスに沿って調整することができ、品質を保証し、リリース速度を加速することができます。これがArtifactoryがJFrog DevOps Platformを強化する完全に自動化されたソフトウェア配布パイプラインの中心的なコンポーネントである理由です。 可能性を追求するため、JFrogクラウドの無料アカウントでArtifactoryを始めましょう。  

  さらに見る
• ArtifactoryでCargoリポジトリを使用する方法

  8月 5, 2021 | < 1 min read

  RustはStackoverflowが実施した最も好きなプログラミング言語の調査で5年連続で首位を獲得しました。C/C++の次のステップとして注目されているこの言語は組込み機器の開発者やIoT向けの堅牢なシステムによって急速に普及しています。 JFrogではRustの開発者を歓迎し、堅牢なバイナリ管理と継続的インテグレーションにどのように貢献するかを紹介したいと思います。私たちはRustプログラミング言語のパッケージ管理システムであるCargoをArtifactoryでサポートするリポジトリに加えました。 86%以上の開発者が熱狂的に支持したRustの特徴とは？また、ソフトウェア開発のライフサイクルを加速するために、ArtifactoryのCargoリポジトリをどのように利用できるのでしょうか？ なぜRustなのか？ Mozilla ResearchはRustを「スピード、メモリの安全性、並列性に重点を置いたシステムプログラミング言語」と表現しています。これらの重要な機能はそのビジョンを支えるものです。 自動ガベージコレクション - RustはRAII (Resource Acquisition Is Initialization) を強制することでリソースリークバグを防ぎ、リソースを所有するオブジェクトがスコープ外に出たときには必ずリソースを解放します。 強力な並列処理のサポート - Rustは並列処理するマルチスレッドプログラミングを安全で効率的に扱えるように設計されています。強力な型、SendとSyncの特性は同期したスレッドセーフな動作を保証し、標準的なスレッドライブラリはRustコードの並列処理を可能にしています。 セーフティチェック - Rustのコンパイラはメモリーセーフティーなどのチェックを行い、クリーンで堅牢なコードを実現します。 再利用可能パッケージ - Rustは開発者が再利用可能なコードユニットをプロジェクト内でプライベートに共有したり、他の人とパブリックに共有することもできるクレートを作成できる強力なシステムを提供しています。 依存関係の管理 - Rust用のCargoパッケージマネージャはパッケージの依存関係をダウンロードしてコンパイルする機能を備えています。 これらの機能は他の人気のある構文機能（複雑なデータ型、mutable/immutableの借用、回復可能/回復不可能なエラー処理など）と合わせて開発者には喜ばしいことです。 リモートCargoリポジトリ フレンドリーで活発なRustコミュニティはオープンソースのパッケージを配布するためにcrates.ioパッケージレジストリを管理しています。Rustプログラマはアプリケーションのコアサービスの大半は、このパブリックライブラリを利用することになります。 チーム間でのRustビルドのスピードと一貫性を担保するために、Artifactoryのリモートリポジトリを使用してcrates.ioをプロキシします。 ArtifactoryのリモートリポジトリはリモートURLで管理されているリポジトリやレジストリのキャッシングプロキシとして機能します。リモートリポジトリのコンテンツとネイティブソースの間に違いはありません。 このDevOpsベストプラクティスを実践することで、あなたとチームは利益を得ることができます。 スピードのためのローカル化 -- プロキシは頻繁に使用するパッケージをクラウドでもオンプレミスでも、ビルドが行われる環境に保持することで、ネットワークのレイテンシーを最小限に抑えます。 接続保護 -- crates.ioプロキシは接続不良や中断によりcrates.ioサーバが利用できない場合やリモートサーバー自体に障害が発生した場合でも利用可能です。  不変性の確保 -- いったんパッケージのバージョンがプロキシの登録後、それは不変で、それを使用する全てのビルドで同じものになります。これによって、パブリックリポジトリへの不適切な強制プッシュによってビルドに何かが入り込むことを防ぎます。 crates.ioのリモートリポジトリプロキシを簡単に設定できます。 Artifactoryで新規のCargoリモートリポジトリを作成 リモートリポジトリに名前を付け、crates.ioのURLを割り当て アプリケーションパッケージのconfig.tomlマニフェストファイルでcrates.ioの代わりにArtifactoryのリモートリポジトリにリダイレクトするように[registry]のデフォルトを設定します。 （手順はArtifactブラウザの「Set Me Up」を参照してください） リモートリポジトリプロキシは読み取り専用ですが、ビルドのためにオープンソースの依存関係を取り込むという日常的な作業のほとんどにとっては当然のことです。crates.ioに公開する必要がある場合は[registries]で名前を定義し、公開する際に--registryオプションで使用することができます。（マニフェスト内のpackage.publishキーでレジストリ名を指定することでレジストリへの公開が可能になります） # Makes artifactory the default registry…

  さらに見る
• フェデレーテッド・リポジトリでマルチサイトDevOpsを実現

  7月 7, 2021 | < 1 min read

  少人数の開発者チームが一つの部屋でアプリケーションを作っていた時代はとうに過ぎ去りました。今やエンタープライズソフトウェアの開発は世界中の複数の拠点に配置されているチームがパッケージを共有するという、高度な共同作業になっています。 エンタープライズ向けに、JFrog Artifactoryは様々なプッシュ/プルレプリケーションのトポロジーオプションによって、マルチサイトレプリケーションを可能にし、地理的に分散したチームはローカルリポジトリで最小限のレイテンシーで同じアーティファクト（バイナリとメタデータ）の利用が可能になっています。 最近では双方向ミラーリング技術であるJFrog Artifactoryフェデレーテッド・リポジトリを導入し、DevOpsチームにマルチサイトのチームやプロジェクトのための設定と管理が容易なオプションを提供しています。このリポジトリミラーリング技術は複数のサイト間のリポジトリのフェデレーテッド・セットを継続して同期します。 JFrog Artifactoryのフェデレーテッドリポジトリにより、企業は以下のことが可能になります。 地理的に分散したチーム間でソフトウェアを共同開発 頻繁に更新されるバイナリをサイト間で安全かつ効率的に同期が可能 グローバルに展開 共有されているすべてのアーティファクトとメタデータがどこでも最新バージョンであるのを確実に実施 ディザスタリカバリのためのレプリケーション フェデレーテッド・リポジトリでグローバルにスケールアップ JFrogのフェデレーテッド・リポジトリは地理的に分散したチームがアーティファクトとメタデータを一括して共有することで、マルチサイト開発を可能にします。 フェデレーションによって、1つのArtifactoryデプロイメント（例えばアムステルダム）のローカルリポジトリは他のArtifactoryデプロイメント（例えばバンコク）のローカルリポジトリと同期するように論理的に結合することができます。このように結合することでアムステルダムのリポジトリにプッシュされたアーティファクトやメタデータは自動的にバンコクのリポジトリにレプリケーションされます。また、このフェデレーションは双方向なため、バンコクのリポジトリにプッシュされたデータもアムステルダムにレプリケーションされます。 このように、フェデレーションに参加したArtifactoryリポジトリは各サイトに対し、グローバルな共有データにローカルでアクセス可能な統一されたリポジトリを提供します。 マルチサイトの同期 容易な管理 フェデレーテッド・リポジトリを使用することで、1つのサイトで承認された管理者が複数のJFrog Platformのローカルリポジトリを作成し、単一のマルチサイトフェデレーションに結合することができます。フェデレーショントポロジーを作成するために、タイムゾーンを越えた異なる物理的なサイトにいるプラットフォーム管理者間で設定を調整する必要はありません。 設定やメンテナンスは提携しているどの物理的なサイトからでも迅速かつ容易に行うことができます。設定やリポジトリの設定に対するすべての変更は全てのフェデレーションメンバー間で自動的に同期されます。 管理者ビュー エンタープライズな拡張性 Artifactoryのユニバーサルパッケージ管理でサポートされている30種類のリポジトリタイプ間でフェデレーションすることができます。もちろん、フェデレーション内のすべてのリポジトリは同じタイプでなければなりませんが、異なるパッケージタイプのために複数のフェデレーションを作成することができます。例えばnpmリポジトリのフェデレーション、Mavenリポジトリのフェデレーション、Dockerのフェデレーションなどが可能です。 リポジトリフェデレーションには同じリポジトリタイプのメンバー（リモートサイトにある異なるJFrog Platformデプロイメント（JPD）のローカルリポジトリ）を最大10個まで含めることができ、地理的に広い範囲をカバーすることができます。 セキュアな信頼関係 フェデレーテッド・リポジトリではバイナリプロバイダ・トークンを使用し、各サイトで証明書を設定することなく、メンバー間の信頼関係を確立します。JFrog Mission Controlは自動的に全てのJPDをセキュアなフェデレーションに対応させますが、セキュアなJFrog PlatformのURLを手動で指定することもできます。 各サイトの管理者は自サイトのJPDで管理しているパーミッショングループを通して、自サイトのユーザーによるフェデレーテッド・リポジトリへのアクセスを可能にしたり、制限したりすることができます。 フェデレーテッド・リポジトリの設定方法 フェデレーテッド・リポジトリを使用するために、JPD間でクロスインスタンス認証（Circle-of-Trust）を設定する必要があります。この設定完了後、プラットフォーム管理者は、事前に定義された権限セットに基づいて、リポジトリに対してCRUD（Create、Remove、Update、Delete）アクションを実行することができます。 1つのフェデレートリポジトリに対して行われた全てのアクションはリポジトリのコンテンツだけでなく、重要な設定変更も含めて自動的に同期され、すべてのフェデレーテッド・メンバーに反映されます。 フェデレーション内において、アーティファクトとメタデータの双方向のミラーリングが行われるのが直接的な接続を宣言したリポジトリ間のみであるということは重要なポイントです。ミラーリングは二次的に接続された他のリポジトリに自動的にカスケード接続されることはありません。 例えば以下の4つのJFrog Platformを導入したマルチサイトの例を考えてみます。 Amazon Web Services (AWS)のクラウドインスタンス フロリダ州オーランドにあるメインデータセンターのオンプレミスサイト カリフォルニア州サンタクララ本社のオンプレミスサイト マサチューセッツ州ウォルサム支社の開発オフィスのオンプレミスサイト これがどのように機能するか、いくつかのトポロジーの例を見てみます。 スター型トポロジー スター型トポロジーではJPD内のローカルリポジトリはフェデレーション内の他のJPDリポジトリに対するセントラルハブの役割を果たします。ハブとなるJPDリポジトリはアーティファクトとメタデータをフェデレーション内の全てと共有し、全てのアーティファクトをハブと共有します。しかし、他のサイトはお互いに共有していません。 この例ではアフィリエイトサイトに接続するためのセントラルハブとして、AWS上のクラウドインスタンスからフェデレーションを構成します。3つのオンプレミスサイトではフェデレーテッド・リポジトリの設定は行われません。 つまり、この例では AWSのリポジトリにプッシュされたアーティファクトはオーランド、サンタクララ、ウォルサムにミラーリングされる オーランドのリポジトリにプッシュされたアーティファクトはAWSにのみミラーリングされる サンタクララのリポジトリにプッシュされたアーティファクトはAWSにのみミラーリングされる ウォルサムのリポジトリにプッシュされたアーティファクトはAWSにのみミラーリングされる オーランド…

  さらに見る
• GitHub対JFrog: どちらがDevOpsのために仕事をしてくれるのか？

  4月 19, 2021 | < 1 min read

  製品を選択し購入するのは仕事をするためです。DevOpsのために、2つの優れた候補から選択することは大きな賭けになります。その採用に企業の成否がかかっています。 最高の候補であるJFrogとGitHubの2つがあります。では、どちらが最適かを判断しましょう。競合する機能だけでなく、どちらが仕事を成功させるための最善の方法を提供してくれるのでしょうか？ 候補: GitHubとJFrog GitHubには素晴らしい経歴があります。ソースコード・コラボレーションツールの業界標準を打ち立て、GitHubのバージョン管理システム（VCS）はすでに開発パイプラインで重要な役割を果たしているかもしれません。現在ではMicrosoftの一部となったGitHubは開発者からの信頼を得ているだけでなく、最新のGitOpsプラクティスを通じて、運用側からも信頼されるようになってきています。 GitHubはCI/CDを実行するためのGitHub Actionsとローカルパッケージ型リポジトリGitHub Packagesに基づいて構築されています。また、マイクロソフトが買収したDependabotを統合し、OSSセキュリティの脆弱性監視を提供しています。 一方、JFrog DevOps PlatformはArtifactoryを利用しています。Artifactoryは多くのモダンなDevOpsプラクティスのパイオニアである優れたバイナリリポジトリマネージャです。JFrog Platformはエンドツーエンドのソフトウェアデリバリのための統一されたシステムの下でソフトウェアを構築（JFrog Pipelines）、セキュア（JFrog Xray）、配布（JFrog Distribution）するのに役立つスケーラブルなソリューションで構成されています。 仕事: 責任と義務 DevOpsを成功させるためには選択したソリューションで重要事項をすべて満たせなくてはなりません。ここではGitHubとJFrogを比較し、それぞれが仕事をどの程度こなすことができるかを見てみましょう。 6つの障害 DEVOPSの成功に向けて | EBOOK リリースの高速化 私たちの長年の経験が証明しているのは「DevOpsの達成はバイナリが全てである」ということです。 ソフトウェア開発の主役はコードであり、品質の良いコードはその書き方を知っている人たちに力を与えることで生まれます。 ソフトウェアデリバリの主役はバイナリであり、品質の良いビルドを作成し、顧客のデバイスに迅速に届けることです。高品質のバイナリはバイナリ管理と配布方法を知っているスマートなシステムから生まれます。 そのためには: JFrog GitHub Automation: Natively integrated CI/CD ✅ ✅ Build Promotion for Release Staging ✅ X Extended Metadata for Traceability ✅ X Advanced Query Language ✅ X Proxy Repository…

  さらに見る