ようこそ
JFrog’s Blog

FILTER BY

JFrogのログ分析をPrometheusとGrafanaで

JFrogのログ分析をPrometheusとGrafanaで

Kubernetes上でJFrog DevOps Platformを実行することは毎日何百万ものアーティファクトを開発者や顧客に提供することを意味しています。しかし、最高のパフォーマンスで運用するには、いくつかの重要な質問の回答が必要です。例えば最もリクエストの多いアーティファクトは何か?最も人気のあるリポジトリは何か?一番のヘビーユーザーは誰か?どのユーザーに問題があり、どのIPからアクセスされているのか? これらの答えを知るためにJFrogから提供されている統合機能はJFrog Platformのアクティビティを監視するためのログ分析を提供し、開発の改善を行うための重要なフィードバックを提供することができます。  K8sで運用している方は2018年にCloud Native Computing Foundation(CNCF)から登場して以来、デファクトのKubernetes監視ソリューションであるPrometheusを既に使用しているかもしれません。可視化ツールのGrafanaと一緒に使用することでアプリケーションやK8sクラスタ自体のパフォーマンス分析のためのセントラル・ダッシュボードを利用できます。 Prometheusベースのモニタリングを強化するためにJFrog log analytics solution for Prometheus and Grafanaを提供しています。この統合により、JFrogプラットフォームのログデータを収集し、運用上のメトリクスを調べて、すでに使用しているモニタリングツールで重要な洞察を得ることができます。 Prometheusが監視ツールとして最適でない場合はSplunk、Elastic、DataDogを利用するためのソリューションも提供しています。 Fluentdのインストール モニタリングおよびロギングの要となっているのはオープンソースのログコレクターであるFluentdです。Fluentdを使用することですべてのJFrogサービスに共通のロギングとモニタリングレイヤを提供することができます。Fluentdは各種プラットフォームにインストールできます。ご利用のプラットフォームのインストールガイドをご覧ください。 以下はRedHatにFluentdのtd-agentをインストールする手順です: $ curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent3.sh | sh さらにPrometheus Fluentdプラグインをインストールする必要があります。このプラグインは、ロギングイベントをPrometheusのHTTPメトリクスインターフェースとして公開します。これについては後ほど説明します。 Fluentdの設定 Fluentdは入力ソース、フィルタ、出力の設定を行うテキスト設定ファイルで構成されています。Prometheus FluentdプラグインはPrometheus用のメトリクスを設定するための構文を提供します。それらはArtifactoryとXrayのログイベントをPrometheusのメトリクスに変換します。ArtifactoryとXray Fluentdの設定ファイルをこちらで提供しています。 適切なfluent.conf.*ファイルを選択し、td-agentを起動します。 fluent.conf.rt - Artifactory version 7 server fluent.conf.rt6 - Artifactory version 6 server fluent.conf.xray - Xray server $ td-agent -c fluentd.config.rt  …
JFrogのログ分析をElasticで

JFrogのログ分析をElasticで

  DevOpsチームはユニバーサル・バイナリ・リポジトリマネージャーとしてArtifactoryを利用していますが、その運用監視は困難な場合があります。複数の高可用性ノードとXrayをJFrog DevOpsプラットフォームとして統合することで運用データはJFrogプラットフォームの各サービスのログに分散されます。 運用チームはリアルタイムのデータマイニングとプラットフォーム監視で得られる貴重なデータの分析を必要としています。以前のブログJFrogのログ分析をSplunkでにて初めてご覧になった方もいるかもしれません。 この機能をより広範囲に利用できるようにするため、JFrogはこの機能をElastic Stackのユーザーに拡張し、ElasticsearchとKibanaの統合を行いました。 Elasticsearchは分散型でスケーラブルな検索エンジンで全文検索、構造化テキスト検索、アナリティクス検索などに利用できます。大量のデータを検索する場合はもちろん、さまざまな種類の文書を検索する場合にも利用されています。 KibanaはElasticsearchの可視化とダッシュボードとして一般的に導入されています。Kibanaを使用した場合、ビルドの可視化やダッシュボードを使ってWeb UIからElasticsearchのログデータを検索することができます。 オープンソースのログ分析テクノロジーを活用する方法をご紹介します。Elastic、Fluentd、Kibanaを活用し、運用チームが価値ある情報を得るための無償のオープンソース・ログ分析プラットフォームを提供します。 Fluentdの使用 まず、JFrog上のオープンソースのデータコレクタであるFluentdをElasticsearchとKibanaの統合で利用できるようにしました。FluentdはJFrogプラットフォームの各製品に対するログ入力、フィールドの抽出、レコードの変換を行い、このデータをJSONに変換します。 すべてのログデータを共通フォーマットで利用できるため、Fluentdはプラグインを介して、お客様が選択したElasticsearchにログデータを送信します。 Fluentdのインストール 各JPDノードにFluentdロギングエージェントをインストールする必要があります。このエージェントは様々なJPDログファイルを処理し、新しいログ行を解析後、対応するレコードに変換し、Fluentdの関連する出力プラグインに送信する役割を持っています。 各ノードにFluentdエージェントをインストールするにはFluentdインストールガイドに記載されている通り、OSの種類に応じた手順を実施します。 例えばRed Hat UBI Linuxを動作させているノードではFluentdエージェント 「td-agent」をインストールする必要があります(このOSではrootアクセスが必要です): $ curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent3.sh | sh Red Hat UBIのuser-spaceにインストールする場合はFluentdのRubyとGemをインストールします: $ curl -O | tar -xvf Fluentdの設定 rootユーザかそれ以外のユーザかにより、Fluentd設定ファイルの配置場所の変更を必要な場合があります。 パッケージマネージャを使用した場合、rootユーザによるインストールではデフォルトでtd-agent.confファイルは /etc/td-agent/にあります。 $ ls -al /etc/td-agent/td-agent.conf -rw-r--r-- 1 root root 8017 May 11 18:09 /etc/td-agent/td-agent.conf rootユーザ以外のインストールでは書き込み権限があればtd-agent.confファイルをどこでも保存できます。td-agentを実行時、-cフラグを利用してfluentdをこのファイルの場所に指定することができます。 設定ファイルはJFrog…
JFrog ChartCenterを公開: コミュニティ用Helm Chartセントラル・リポジトリ

JFrog ChartCenterを公開: コミュニティ用Helm Chartセントラル・リポジトリ

公開されているHelm chartsの数は増え続けており、コミュニティにとっては素晴らしいことですが、膨大なHelm chartとHelm chartリポジトリを調べるのは困難な状況となっています。 船の船長が必要とするのは安全に到着するための詳細なリストだけではありません。氷山の一角以外の見えない場所にも危険があります。 このため、開発者コミュニティに公開するHelm Chart用の無償のセントラル・リポジトリであるChartCenterを発表いたします。  ChartCenterのエッジ ChartCenterのUIを通して、何千ものKubernetes Docker registryパッケージから必要なものを検索することができます。多くの公開リポジトリに分散しているアプリケーションを検索して利用することができます。ChartCenterは検索サービスのHelm HubやArtifact Hubに似ています。 しかし、ChartCenterはただのカタログではありません。Artifactoryを搭載したChartCenterは不変のバージョンを保持するHelm Chartリポジトリです。そのため、Helm CLIはすべての公開されているHelmChartを単一の場所から確実にダウンロードすることができ、真の単一ソースとなります。 すべての保存されたHelm Chartはスマートに利用できるように必要とする重要な情報を提供する堅牢なメタデータで管理されています。これらの機能がユーザにとってどのような意味を持つかをご紹介します: 不変、バージョニングHelm Chart ChartCenterはすべてのChartバージョンの単一の情報源です。今日使用しているHelm Chartのバージョンが先月または昨年使用したものと同じであることを常に確認できます。たとえ Helm Chartの所有者がリポジトリを不適切に変更や削除をした場合も同様です。ChartCenterは変更が発生した場合、そのバージョンにフラグを立てます。また、ChartCenterは元のリポジトリが何らかの理由で利用できなくなった場合、フェイルセーフ機能も提供しています。 ChartCenterはすべてのHelm Chartのバージョン、apiVersion、appVersionのメタデータも保持します。 使用データ ChartCenterはHelm Chartが別のHelm Chart(Subchartとして)の依存関係として使用されている場所も通知されます。 依存性の識別 HelmのChartバージョンごとに、ChartCenterではDockerイメージやSubchartなど、使用されているすべての依存関係を確認できます。UIで各Dockerイメージの依存性があるすべてのレイヤーを確認することができます。 脆弱性の確認 ChartCenterはJFrog Xrayの再帰的スキャンを実行し、Helm Chartのすべての依存関係のあるコンテナイメージに対して脆弱性分析を実行します。そのため、K8sアプリをデプロイする前に、あらゆるK8sアプリのセキュリティ・リスクを評価することができます。 メンテナのためのセキュリティ対策 また、ChartCenterではChartのメンテナがノートの提供やUI上でChartのセキュリティの概要を確認する機能も提供しています。CVEにタグを付けてメモを提供できるようにsecurity-mitigation.yamlファイルを開発しました。これらのメモはメンテナが更新されたChartで yamlを提供すると利用できるようになり、以下のように表示されます: ChartCenterの利用 これまではChartCenterの機能の一部を説明しましたが、ここからはHelmクライアントで使用する方法を説明します。 ステップ1: ChartCenterをHelmリポジトリとして追加 HelmクライアントにChartCenterリポジトリを単一のソースとして利用するための設定を追加します: $ helm repo add center https://repo.chartcenter.io $ helm repo update $…
AWS CodeArtifact vs Artifactory: バイナリー管理はどちらを選ぶべきか?

AWS CodeArtifact vs Artifactory: バイナリー管理はどちらを選ぶべきか?

Artifactory OSS版の提供と同時にJFrogの設立以来、私たちは堅牢なアーティファクト管理ソリューションがなければスケール、スピード、信頼性のあるソフトウェアも提供できないと主張してきました。それから10年以上経った今、業界の他のベンダーもようやく理解し始めています。 AWSはバイナリ管理のためのCodeArtifactサービスを先日発表しました。以下ではJFrog ArtifactoryとAWS CodeArtifactの違いや、どちらのソリューションが一般的なユースケースに最も適しているかなど、知っておくべきことをすべて比較しています。 Artifactory - JFrog Platformのバックボーン - は当社が市場に投入した最初の製品でした。開発者である私たち自身がバイナリマネージャを持たない苦労を理解していたため、業界初のアーティファクト管理ソリューションを発表しました。以前は存在しなかったこの新しいカテゴリーのツールは、あらゆる開発においての重要な柱となりました。今日においてもArtifactoryは最も人気のあるバイナリ管理ソリューションであり、DockerレジストリとHelmリポジトリを含む、27種類以上のパッケージタイプを1つにまとめてサポートする唯一のユニバーサルな製品です。 ここではJFrog ArtifactoryとAWS CodeArtifactの主な違いと、それが何を意味するのかを見てみましょう。 AWS CodeArtifactとJFrog Artifactoryの比較 AWS CodeArtifactはS3ベースのマネージドアーティファクト/バイナリリポジトリです。AWSマーケットプレイス(および他のパブリッククラウド)で提供しているベースレベルのJFrog Artifactory SaaSサービスとコンセプトが似ています。  この9つの重要な違いを見ていきましょう: ユニバーサルパッケージ管理: CodeArtifactはユニバーサルなパッケージマネージャではありません。3つの技術しかサポートしていないためです。Mavenのサポートはまだ初期段階であり、本番環境で使用できるレベルではありません。Mavenメタデータはユーザが手動でアップロードしなければなりません。これでは同じパッケージ、特にユニークなスナップショットの同時バージョンのデプロイを生かすことができません。CodeArtifactは同じリポジトリへの複数のスナップショットのアップロード(これは開発チームでは同時に実施される)がサポートされていません。 JFrog Artifactoryは27以上のバイナリタイプをサポートしています。Artifactoryは汎用リポジトリも提供しており、ユーザはリリースの一部である追加のファイルタイプ(イメージ、zipファイル、ドキュメントなど)を一元的に管理することもできます。 AWS CodeArtifact (全て) JFrog Artifactory (一部) Maven/Gradle npm/Yarn pip/twine Maven/Gradle npm/Yarn pip/twine Nuget RPM Debian Go Docker Helm Conan (C/C++) GitLFS PHP Composer RubyGems VCS N/A Generic   どちらのソリューションもユーザは外部リポジトリをプロキシすることができます。しかし、CodeArtifactはオフィシャルなアップストリームリポジトリのプロキシしかサポートしていません:…
AWSクイックスタートを使用してArtifactory HAをAWSにデプロイする

AWSクイックスタートを使用してArtifactory HAをAWSにデプロイする

AWS上のリポジトリマネージャーとしてのJFrog Artifactory Recently updated on: June 1, 2020 JFrog Artifactory Cloud on AWSは開発者とDevOpsエンジニアのためのホスト型ソリューションであり、ソフトウェア開発のライフサイクル全体を通して完全なコントロール、可視化、バイナリ管理を提供します。クラウドベースの開発により、ビルドおよびリリースプロセス全体の透明性とコントロールがDevOpsチームに提供されます。 この度、AWSクイックスタートを全くの新機能で提供することを発表しました。これには可用性の高い3つのAWSクイックスタートによりArtifactory Enterpriseのデプロイが出来る便利な機能を含みます。これで、高可用性(HA)構成でのArtifactory EnterpriseのAWSへのデプロイが簡単かつ迅速に行えるようになりました。クイックスタートはAWS CloudFormationのテンプレートを使用した、自動化されたデプロイメントのサンプルです。AWS上に重要なテクノロジーをデプロイすることで、オプションが多く複雑になりがちなデプロイメントの設定を簡略化します。また、デフォルト設定を推奨し、素早く簡単なデプロイを可能にします。 WHAT’S NEW JFrogのクイックスタートにおいて、皆さんのデプロイメントを向上する次の新機能を提供します。 新しいバージョンであるArtifactory 7にアップデートされ、統合UIがお使いいただけるようになりました。 AMIベースとなり、インストールが更に高速化されました。 Postgresのサポートが提供されます。 エンタープライズのDevOpsチームがより強化されたセキュリティoktaCentOSベースのイメージにも対応しました。 AWSクイックスタートを使ってArtifactoryをデプロイすることの5つのメリット AWSクイックスタートを使ってArtifactoryをデプロイする主なメリットは次のとおりです。 EC2やEKS、ECSでクイックスタートを使用すれば、Artifactoryのクラスターをすぐにデプロイ出来ます。 新規・既存いずれのクラスターにも適用できます。 Infrastructure as Codeを実現します。コード化により、インフラも単なるコードとして扱うことが出来ます。コードエディターで編集し、バージョン管理システムで管理し、本番環境へデプロイする前にチームメンバーと一緒にファイルをレビューすることが出来ます。 自動化とデプロイメントを管理します。AWS CloudFormationは、安全で再現性の高い方法でリソースをプロビジョニングするため、手動での作業やカスタムスクリプトの作成を行わなくても、インフラストラクチャーやアプリケーションの構築・再構築が可能になります。 スタックを管理する際に実行すべき正しい操作を決定し、エラーが検出された場合は自動的に変更をロールバックします。 AWSにArtifactoryをデプロイするための3つのクイックスタート どのクイックスタートもデプロイメントオプションごとのテンプレートを提供しています。これによりCIDRブロック、インスタンスタイプ、そしてArtifactoryの設定も変更することが出来ます。 クイックスタート1: AWSクラウドにArtifactoryをデプロイする このクイックスタートを使用して、Amazon EC2でJFrog Artifactoryを自動で設定してください。デプロイメントには次のものが含まれます。 複数のAvailability Zoneにまたがる高可用性アーキテクチャー AWSのベストプラクティスに従い、AWS上に独自の仮想ネットワークを提供するためのパブリックおよびプライベートのサブネットで構成されたVPC パブリックサブネット上には プライベートサブネット内のリソースがアウトバウンド・インターネットアクセスするための管理可能なネットワークアドレス変換(NAT)ゲートウェイ パブリックおよびプライベートのサブネット上のEC2インスタンスにSSHでインバウンドアクセスするためのオートスケーリンググループ内のLinux踏み台ホスト ポート80または443番でArtifactoryのプライマリーノードやプライベートノードに接続するパブリックサブネットと繋がるクラシックロードバランサー プライベートサブネット上には プライベートサブネットまたはポート3306番経由でのみ接続可能なAmazon RDSインスタンス上のMySQL プライマリーノード向けとセカンダリーノード向けの2つのAmazon EC2オートスケーリンググループ リポジトリのストレージとして暗号化されたプライベートなAmazon…
OpenShiftでJFrog Enterpriseをスムーズに実行するOperatorを提供

OpenShiftでJFrog Enterpriseをスムーズに実行するOperatorを提供

Red Hat OpenShiftとJFrog Artifactoryは共にクラウドネイティブなため、エンタープライズ規模でコンテナ化されたソフトウェアをスムーズに開発することができます。また、JFrog Enterprise用の認定済みOpenShift Operatorが新たに利用可能となったことで、より強固になりました。 Kubernetesをスケールに合わせてビルド 1,700以上の組織から信頼されているRed Hat OpenShiftはエンタープライズKubernetesアプリケーションプラットフォームをベースとしたハイブリッドクラウドです。JFrog DevOpsプラットフォームの中核をなすバイナリ管理の業界標準であるJFrog ArtifactoryはFortune 100社の多数を含む5,000社以上の企業で使用されています。 JFrog EnterpriseがOpenShift同様に複数チームで構成されている組織の拡大するニーズに合わせてどのように構築されているかをご紹介します: 主要なすべてのパッケージタイプ用のリポジトリは言語(Java, npm, NuGet, Python, Golangなど)と実行環境を問わず開発作業を効率的に行えます。 高可用性とプッシュ/プル・レプリケーションにより、世界中で毎時間実行される何百ものCIのビルドが可能です。 オンプレミスでもクラウドでも同じ操作と機能を有し、完全にハイブリッドです。 DockerレジストリとHelm chartリポジトリのサポートにより、Artifactory Enterpriseは完全にトレース可能なKubernetesレジストリとして機能し、OpenShift K8sにデプロイ可能な信頼できるソフトウェアのリポジトリとして機能します。   JFrog EnterpriseのOpenShift Operator OpenShift OperatorはKubernetesアプリケーションをパッケージング、デプロイ、管理するオペレーターです。これらのオペレーターはコンテナ化されたソフトウェアを実行する際の複雑な処理を行い、OpenShift Container Platformの状態を監視して、自動化したリアルタイムな運用が可能です。 JFrog Enterpriseで利用可能なOpenShift OperatorはOpenShift 4と互換性があり、Artifactoryのデプロイを自動的にモニタリングします。これによりK8sクラスタでArtifactoryの継続運用が可能となります: JFrog Artifactoryを安全に実行するためのRBACポリシーの設定 JFrog Artifactoryを高可用性(HA)モードでデプロイ 必要なストレージとサービスのエンドポイントをプロビジョニング DevSecOps用のJFrog EnterpriseサブスクリプションにJFrog Xrayを追加することでXrayの継続的セキュリティのインストールとメンテナンスを同様に支援するために、2つ目のOpenShift Operatorが利用可能です。 OperatorによるJFrog Artifactoryのデプロイ ArtifactoryでSSLを利用する場合は秘密鍵と証明書にKubernetes ingressでtlsSecretNameも指定する必要があります。このK8s secretはOpenShift Developer CLIのoc createコマンドで作成できます。…
GKEにArtifactory HAを新規インストールする

GKEにArtifactory HAを新規インストールする

GKEあるいはKubernetesクラスタへのArtifactoryのインストールは複雑になりがちです。いくつかのシナリオを考え、UIとコマンドラインを行ったり来たりして切り替え、長いHelmコマンドを作成し、利用可能なパラメータを検索しなければなりません。証明書、ライセンス、データベース、ノードなどの設定もしなければなりません。しかし、それだけではありません。つまり、バグフィックス、セキュリティパッチ、新機能がリリースされるたびに、それが新しいArtifactoryのバージョンにアップグレード可能であることを確認しなければいけません。 JFrog Artifactoryは、GCP マーケットプレイスで利用できるようになり、設定とインストールが非常に簡単になりました。この方法でArtifactoryをインストールするとフォールトトレラント、高可用性、安全性、アップグレードがわずか数ステップで可能になります。何よりも、設定は公式のJFrog Helm Chartsに基づいているため、問題が発生した場合でもサポートされており、継続的に改善されています。JFrog Helm Chartsはオープンソースです。自由に使用して、必要に応じてカスタマイズしてください。 それでは、セットアップを始めましょう。以下の手順に従って、JFrog Artifactoryをインストールしてください。   始める前に 以下を準備下さい。 アクティブなGoogle Cloudアカウント 対応するSSL証明書を持つドメイン名 すでにこれらをお持ちの方は、さっそく始めてみましょう。 Step 1: Google Cloud Platformに移動し、Marketplaceを開きます。 Step 2: 「JFrog Artifactory Enterprise」を検索します。 Step 3: リストを開き、「Configure」をクリックします。 Step 4: 新しいClusterとNamespaceを選択または作成します。App instance nameはk8sの63文字の制限を避けるため、6文字以内にしてください。master keyはopenssl rand -hex 32を実行して手動で生成するか、そのままにしておきます。必要に応じて静的IPアドレスとNginx Secret名を指定し、「Deploy」をクリックします。 Step 5: デプロイが完了したら、Kubernetes Engine > Services & Ingressと進み、Load balancerのIPアドレスを取得します。 Step 6:デフォルトのユーザー名:admin、パスワード:passwordでログインします。 初期設定の際には、デフォルトのパスワードをより安全なものに変更することを忘れないでください。 これで完了です。 GCPマーケットプレイスでは、その他のJFrogソリューションもご利用いただけます。
JFrogのログ分析をSplunkで

JFrogのログ分析をSplunkで

両方を使用することで最良の結果が生み出されます。 単一のユーザーインターフェースで動作するように、すべてのソリューションを統合したJFrog DevOpsプラットフォームを構築しました。Artifactory 7によるこの統合はソフトウェアのビルドパイプラインを完全に制御できます。 また、プラットフォームの運用を維持するためにはプラットフォーム全体の運用状況をリアルタイムで統一的に把握する必要があります。すでにお使いの分析/可視化ツールを利用して、非常に容易に実現できるツールをいくつか提供しています。 ここでは、これらの新しい JFrogツールをインストールし、Splunkを利用したJFrogプラットフォームの動作を監視する方法をご紹介します。 統合プラットフォームのためのログ集約 JFrogプラットフォームは多数のマイクロサービスによって実現されており、それぞれが独自のログレコードを持っています。高可用性のJFLogプラットフォーム・デプロイメント(JPD)のように複数のノードに分散している場合、プラットフォームの全操作はネットワーク上の25以上のログに分散している可能性があります。 運用チームはパフォーマンスを分析し、運用上の問題を追跡するために、このJPDログデータを1つに集約する手段を必要としています。また、小規模な企業のJPDであっても毎日何百万ものトランザクションイベントを記録している場合、オペレータはそのデータの詳細を確認するためには強力な分析ツールを利用する必要があります。 Splunkの準備 Splunkがログデータを受信できるようにするにはSplunkでHTTP Event Collector (HEC) を設定する必要があります。Splunk EnterpriseでHECを設定することができます。 Splunkで既に他の用途でHECが有効になっている場合でも、JFrogプラットフォームで排他的に使用するための認証トークンを作成する必要があります。     HECの設定から以下の内容を確認しておく必要があります。 HECトークン – 認証のために作成したGUID HECホスト – HECを実行するSplunkインスタンス HECポート – HECグローバル設定で指定したポート番号 この設定によりSplunkはJFrogプラットフォームからのメッセージを受信できるようになります。 Fluentdの使用 まず、オープンソースのデータコレクタであるFluentdを利用できるようにしました。FluentdはJFrogプラットフォームの各製品に対するログ入力、フィールドの抽出、レコードの変換を行い、このデータをJSONに変換します。 すべてのログデータを共通フォーマットで利用できるため、Fluentdはプラグインを介して、お客様が選択した分析ツールにログデータを送信します。 Fluentdのインストール 各JPDノードにはFluentdロギングエージェントがインストールされている必要があります。このエージェントは様々なJPDログファイルを処理し、新しいログ行を解析後、対応するレコードに変換し、Fluentdの関連する出力プラグインに送信する役割を持っています。 各ノードにFluentdエージェントをインストールするにはFluentdインストールガイドに記載されている通り、OSの種類に応じた手順を実施します。 例えばRed Hat UBI Linuxを動作させているノードではFluentdエージェント 「td-agent」をインストールする必要があります(このOSではrootアクセスが必要です): $ curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent3.sh | sh インストール後、「td-agent」は指定されたディレクトリに存在します: $ which td-agent /usr/sbin/td-agent また、お使いの分析ツールに合ったFluentd出力プラグインをノードにインストールする必要があります。Splunkの場合はSplunk Enterprise用のFluentdプラグインになります。…
Mavenを用いたデプロイの上手な扱い方

Mavenを用いたデプロイの上手な扱い方

私達が開発したコードはアーティファクトとしてパッケージ化され、他のソフトウェアコンポーネントを開発する際に依存先として利用されます。こうしたアーティファクト同士の依存に伴う複雑な課題を解決するには、JFrog Artifactoryのようなアーティファクト・リポジトリマネージャーが頼りになります。   Artifactoryは効果的なCI/CDパイプラインの一部として、大小を問わず多くの組織でバイナリを管理するための基盤となっています。   このブログ記事では開発チーム全体でのバイナリを管理する際の課題について、接続先情報を管理するためのセキュリティのベストプラクティスに焦点を当てて具体的に説明します。なお、Mavenを使用して構築されたJavaプロジェクトを例として扱いますが、どのようなプログラミング言語とパッケージタイプにも同じアプローチが適用できます。   JFrog CLIについて少しおさらい 具体的な課題と解決策を説明する前におさらいしましょう。JFrog CLIはJFrog製品へのアクセスを自動化するためのスマートクライアントとして、シンプルなインターフェースを提供します。チェックサムの最適化によるスマートなアップロードとダウンロード、File Specsのサポート、ビルド統合機能など、JFrogプラットフォームに関する多くの機能があります。また、Mavenなど人気のあるパッケージマネージャと統合し、JFrogプラットフォームと一緒に使用すると、より力を発揮します。   課題: リポジトリの接続先情報を安全に管理する 次のようなシナリオを考えてみましょう。あなたのアプリケーションはJavaで書かれており、Mavenを使ってビルド、パッケージ化されています。MavenはArtifactoryからプロジェクトの依存関係を解決し、アプリケーションのJARを作成します。これはローカルのsettings.xml内で設定されるため、開発者は依存関係がArtifactoryのMavenリポジトリから解決されていることに気付かないでしょう。プロジェクトはローカル環境でのビルド後、テストも実行されており、すべて正常に動作しています。   では、CI/CDパイプラインを見てみましょう。使用しているCIサーバー(Jenkins、CircleCI、またはJFrog Pipelinesなど)は継続的に(または定期的に)ソースコントロール・リポジトリをポーリングし、それに応じてコードをビルドしてテストするためにMavenを呼び出します。すべてが上手くいくと、新しいスナップショット・バージョンがバイナリ・リポジトリにデプロイされます。   しかし、Mavenはどのようにして新しいスナップショット・バージョンのデプロイ先を知るのでしょうか?   Mavenのデフォルトのデプロイプラグインを使用している場合、POMとsettings.xmlファイルにデプロイリポジトリへの接続先が含まれている必要があります。ほとんどの場合、開発者はビルドしたアーティファクトを直接デプロイすることはなく、デプロイリポジトリにアクセスすることもありません。つまり、CIサーバー専用のsettings.xmlファイルを維持する必要があるということです。また、POMで設定したサーバーIDがsettings.xmlのIDと一致している必要があります。   pom.xml [...] <distributionManagement> <repository> <id>internal.repo</id> <name>MyCo Internal Repository</name> <url>Host to Company Repository</url> </repository> </distributionManagement> [...] settings.xml [...] <server> <id>internal.repo</id> <username>maven</username> <password>foobar</password> </server> [...] この方法でデプロイメントターゲットを管理するのは不便です。異なる開発チームで管理され、異なるデプロイメントリポジトリを持つ複数のプロジェクトがある場合は、さらに厄介になります。 解決策: JFrog CLIを使用する この問題を簡単に解決する方法を紹介します。MavenリポジトリをホストするのにJFrog Artifactoryを使用している場合に利用できる方法です。開発者の作業には変更を加えず、CIサーバー側を更新することで実現します。CIパイプラインが直接Mavenを呼び出すのではなく、Jfrog CLIを通してMavenを呼び出すのです。  …
JFrog CLIがあなたをサポート

JFrog CLIがあなたをサポート

JFrog CLIはbashとzshでオートコンプリートをサポートするようになりました。この機能により、Bashとzshコマンドを入力し始めるだけで、CLIクライアントが使用可能なオプションを表示するようになりました。タブを使ってオプションをスクロールすることもできます。 JFrog CLIはJFrogソリューションを使用した自動化作業を簡素化できます。例えば、JFrog DistributionワークフローでCLIを使用し、集中型プラットフォームでソフトウェアリリースの管理ができます。ご参考までに、いくつかの便利な機能をご紹介します。 並列複数アップロードとダウンロード チェックサムの最適化 一般的なビルドのFile Specs Maven, Gradle, Go, npm, nuget, Dockerのビルド統合とビルド情報 セキュリティ拡張 JFrog CLIについての詳細 > それでは、この機能の設定方法について説明します。 JFrog CLIのダウンロードとインストールを開始します。 Bashでオートコンプリートを設定する Bashのオートコンプリートを設定するには2つの方法があります: Homebrewを使用: jfrog-cliをインストールするとHomebrewは自動的に'<HOMEBREW_PREFIX>/etc/bash_completion.d/jfrog'へbash補完スクリプトをインストールします。 Homebrewの補完をbashで利用できるようにする場合、こちらの手順をご参照ください。 マニュアルインストール: ‘jfrog completion bash’コマンドを実行します。 指示に従ってインストールします。 zshでオートコンプリートを設定する zshのオートコンプリートを設定するには2つの方法があります: oh-my-zshを使用: テキストエディタで$HOME/.zshrcを表示します。 プラグインリストに‘jfrog’を追加します。例えば、plugins=(git mvn npm sdk jfrog) 詳細はこちら > マニュアルインストール: ‘jfrog completion zsh’コマンドを実行します。 指示に従ってインストールします。 JFrog CLIを使用して、実際にお試し下さい!!