IBM Cloud Use Caseの記事シリーズについて
お客様のUse Caseの中で、複数のIBM Cloudサービスを利用することが多いです。
このシリーズでは、個別のIBM Cloudサービスの紹介ではなく、Use Caseごとに技術情報を説明していきます。
今回のUse Caseとは
‐ 達成したいこと
お客様のファイルはIBM Cloud上のObject Storage Bucketに保管しています。
新しいファイルがBucketにアップロードしたら、同じファイル操作を行いたいます。例えば、ファイル名にTimestampを追加したり、ファイルを別の場所に移動したりします。詳しい操作内容はPython Codeの内容に依存し、Use Caseの実現にはあまり影響がないです。
‐ 本来のやり方
移行する前に、IBM Cloud上のCloud Functionsというサービスを利用されています。下記の図に示すように、Python CodeはCloud FunctionsのAction機能で実行され、実行のタイミングはCloud FunctionsのTrigger機能で管理されます。
ただし、IBM Cloud上のCloud Functionsサービスは今年(2023年)の年末でEnd of Marketingとなり、来年(2024年)の六月末にEnd of Supportとなります。Code Engineに移行することは検討されています。
‐ 現在のやり方
先ずは、Code EngineのSubscription機能でICOS Bucketを監視して、変更があったらPython Codeの実行をトリガーすることができます。
次に、Code EngineでPython Codeを実行するために、Applications、Jobs、Functionsという３つの方法がありますが、このUse Caseに対して、Jobsが最適だと思います。なぜかというと：
‐ Applicationsは継続的なサービスとして24時間稼働するように設計されています。例えば、Web Serverを実行します。
‐ Code EngineのFunctionsはCloud Functionsにとても似でいるため、移行にはCode EngineのFunctionsが一番良いと自然に考える方もいるかもしれません。ただし、SubscriptionよりFunctionsをトリガーすることができません。
従って、Code EngineのJobsを使用することになります。
Use Caseの実現 _ Jobsの作成
設定の流れ
- Source Codeの準備
- Code EngineのProjectを作成
- Code EngineのJobsを作成
1. Source Codeの準備について、
Jobsを利用する際に、Cloud FunctionsのようにSource CodeをConsole画面でCopy‐Pasteすることができません。Code Repositoryに格納することが必要です。
そして、Source Codeには外部のPython libraryやPackageをImportすることがある場合、依存関係の説明が必要です。具体的に、Python Main()は__main__.py という名前のファイルに配置され、依存関係はrequirements.txtという名前のファイルに記載することが必要です。
依存関係について具体的な説明方法は、下記のスクショのようになります。つまり、それぞれの外部libraryやPackageのバージョンを記載することになります。
更に、Source CodeにはImportされたものはibm_boto3 であり、依存関係にはibm-cos-sdkと記載されることに気付いたかもしれません。 実は、IBM ICOSのPython Packageはibm-cos-sdkと呼ばれており、requirements.txtでibm_boto3のバージョンを指定すると、後のSource Code Build作業がFailedとなることをご注意いただければと思います。
2. Code EngineのProjectを作成
Projectの作成が簡単なので、手順とスクショを割愛して、Jobsの作成画面から説明いたします。
3. Code EngineのJobを作成
Python Codeから実行するため、Jobsの作成画面でContainer imageではなく、Source Codeを選択して、Github RepositoryのURLを入力します。次に、Specify build detailsをクリックして、Buildについて設定しておきます。
Specify build detailsに最初のステップはSourceについての設定であり、入力すべきの内容は自分のRepo設定に依存します。私のSample Repositoryを公開していますので、Access情報は要りません。Branchがmainのままで、Context directoryも入力せずにNextにいきます。
次はStrategyの設定になります。私はDockerfileを用意していないので、ここでSource Codeから自動的にContainer ImageをBuildできるCloud Native Buildpackを選択します。TimeoutとBuild resourcesがデフォルトのまま、Nextにいきます。
最後はOutputのステップで、BuildできたContainer Imageの保管場所を設定することです。もちろんDockhubなどの外部Registryが利用可能ですし、IBM Cloud上の既存のPrivate Contrainer Registryも設定可能です。
他のJobsの設定を特に変更なしで、Jobsを作成します。Build作業が数分ぐらいの時間がかかります。
Jobsの状態がBuild completedに表示されたら、Jobsの作成が完了です。
Use Caseの実現 _ Subscriptionの作成
ICOS Bucketを監視して、新規ファイルが格納したら、先に作成したJobsを実行する機能はSubscriptionです。
ProjectのMain MenuにEvent subscriptionをクリックして、右側のCreate ボタンをクリックします。
現時点は、Subscriptionは定期的にTrigger、そして、ICOS Bucketの変更によりTrigger、Event StreamよりTrigger、３つのTrigger方法を提供しています。ここでCloud Object Storageを選択して、Subscriptionの名前を入力して、Nextに行きます。
次の画面で、監視対象になるICOS Bucketを設定して、Nextにします。
ここでTriggerの対象になり、先に作成したJobsに設定して、Nextにします。
Summaryの画面で設定したことを確認して、Createをクリックします。
Use Caseの実現 _ 効果を確認
では、対象であるtestbucket-helenとのICOS BucketにBook1.xlsファイルをアップロードして、Jobsを実行されるかどうか、確認します。
アップロードしたら、Bucketの画面で2023-11-13 6:53 PMという操作の時間情報がわかります。
次にJobsの情報を確認しましょう。
Job runsというタブで、ファイルがアップロードしてから約一分後にJobsが正常に実行されたことがわかります。
そして、実行履歴jobdefinition-b6-bmz7sをクリックすると、実施した際にSubscriptionから来た情報、及び、当時Jobsの詳細設定が確認できます。
後は、右側のLaunch loggingでLog Analysisの画面でも実行情報を確認可能です。（多少遅延も出てます。）
まとめて
このUse Caseを実現するため、主にCode Engineについての説明は、以上になります。
特に注意点として、
‐ Code EngineのFunctionsはSubscriptionよりTriggerすることは、現時点ではできないので、Jobsのご利用が必要
‐ Python Source CodeにImport xxxがある時に、依存関係を明確に記載することが必要
‐ ICOS Python Library ibm_boto3を利用すれば、依存関係にはPackageであるibm-cos-sdkのバージョンを説明必要
Code Engineの利用をご検討の際に、ご参考になれば幸いです。