ao-iroの投稿 - Crieit

Arch Linux（WSL2）にazure-cliをインストール

2023-03-25T17:59:38+09:00

Arch Linuxに（WSL2）にazure-cliをインストールした際の備忘録。

１．必要なパッケージのインストール
　下記に記載のあったパッケージをインストール。
　Python 3.10.10
　libffi　（何かの依存関係でインストールされていた）
　openssl-1.1
　Linux に Azure CLI をインストールする

２．azure-cliのインストール
　yay -S aur/azure-cli　でインストール

３．azure devopsのインストール
　下記を参考にazure devopsをインストール。
　１から４まで実行すると、デフォルトの組織、プロジェクトの設定までできるのでやっておく。
　Azure DevOps CLI の概要

４．PATの設定
　Azure DevOpsにcliで接続するために、下記を参考にPATを作成。
　PATは作成時にトークンが表示されるが、ウィンドウを閉じると二度と確認ができないため、環境変数に設定するなどをして保存しておくこと。
　個人用アクセストークンを使用する

５．az loginの実行
　az login --use-device-code　を実行してログイン。
　az loginでログインしようとすると、「localhostに接続できません」と表示されるので、オプションをつけて実行する。

６．az devops loginの実行
　az devops login --organization https://dev.azure.com/{Organization}　を実行してログイン。
　az loginを事前にしていればトークンの指定は不要、とのことだけど、トークンの入力を促すメッセージは表示されるし、トークンを入れても失敗と表示される。
　だけど、接続はできるようになっている。理由は不明。
　トークンの指定不要であればPATはいらないのでは、と思ったけれど、PATをrevokeすると接続ができなくなるので、PATは必要。

azコマンドでリソースを参照できること、az boardsでワークアイテムの登録までできることを確認。

Arch Linux（WSL2）にCarbonをインストール（2023/03/21時点で未達）

2023-03-21T22:33:28+09:00

Arch Linux（WSL2）にCarbonをインストールしてみようとした際の流れを記載。
2023/03/21時点で、エラーを解消できずに未達。

１．必要なパッケージをインストール
　必要と思われる下記のパッケージをインストールした。
　　・bazel 6.0.0-2
　　・clang 15.0.7-2
　　・llvm 15.0.7-2
　　・lld 15.0.7-2
　　・libc++- 15.0.7-3
　　・libunwind 1.6.2-2

２．Carbonコードをgitからクローン
　Getting startedを参照。

３．ビルドと実行
　Getting startedを参照。

ここで下記のエラーが発生。
libunwind.aが見えていないようなんだけれど、インストールはできていた。
.bash_profileにも「LD_LIBRARY_PATH」を追加してみたけど、エラーは解消できず。
オプションをつけて、「bazel run //explorer -- ./explorer/testdata/print/format_only.carbon --linkopt=-L/usr/lib」で実行してみても変わらなかった。
どうすればいいのかな。
（2023/03/25追記）lddでライブラリを追加できるか試したけれど、参照できていないlibunwind.aは静的ライブラリなので、lddでは追加できない模様。

【参考】Ubuntu 20.04（WSL）で試してみた結果
　① 必須パッケージのインストール
　　セットアップコマンド（Debian または Ubuntu）
　② bazelのインストール
　　上記だとbazel、llvmのインストールに失敗したため、個別に対応。
　　Ubuntu への Bazel のインストール
　 ③ 下記を参考にセットアップを実施
　　llvmのインストールなど、設定を追加
　　Linux(WSL)でCarbonを動かしてみた
　 ④ 実行
　　gitからcloneして実施してみたが、下記のエラーが発生した。
　　
　⑤ bazelでプログラムだけでなく「carbon-explorer」もコンパイルしてメモリが足りていないのかな、と考えて「carbon-explorer」をインストール。
　　carbon-explorerをインストール
　⑥ 実行
　　できた！
　　

Azure Data Factory、Synapse AnalyticsとAzure DevOpsの連携

2023-03-21T19:48:40+09:00

何回やっても時間が空くと忘れるのでメモ。
Synapse Analyticsの場合も同じだったので、Synapse Analyticsで実施する場合は、下記のAzure Data FactoryをSynapse Analyticsに読み替える。

１．Azure DevOpsにサインインする。
　Azure Data Factory（以降、ADF）と連携する、組織、プロジェクトを作成する。
　公開しないのであれば、Privateで問題ない。

２．組織をAzure AD登録する。
　ADFと連携する組織の「設定」から、Azure AD連携を行う。
　この時、Azure AD連携を行うとサインアウトになって、再度サインインが必要となった。
　次にサインインする場合は、Azure DevOpsの更新HPから「無料で始める」をクリックする。
　サインインすると無料アカウントのディレクトリになっているので、ディレクトリの切り替えを行って、Azure AD登録したディレクトリを選択すると、作成した組織、プロジェクトが確認できる。

３．リポジトリを初期化する。
　プロジェクトの「Repos」から、リポジトリの初期化を行う。
　mainブランチが設定される。

４．ADFと連携する。
　ADFのFactory Studioにサインインし、管理画面の「Source control」＞Git Configurationを選択して、Azure DevOpsと連携設定を行う。
　Azure AD登録をしていない組織は表示されない。
　リポジトリ、コラボレーションブランチ、発行ブランチなどを設定し、「適用」をクリックする。

VSCode＋WSL2（ArchLinux）＋Rの環境設定

2022-08-21T16:18:27+09:00

WSL2（ArchLinux）にRをインストールして、VSCodeで動かすために行った設定のまとめ

１．WSL2にRをインストール
yay -S community/r-base

２．WSL2にtck/tlをインストール
※これをインストールしないと、文字化けを改善するためのlanguageserverを設定するためのダイアログが表示できず、文字化けを解消できない。
yay -S aur/r-tcltk2

３．WSL2にr-jsonliteをインストール
jsonファイルを読み込むためのものなのか、これをインストールしないとVSCode側でエラーメッセージが表示される
yay -S r-jsonlite

４．Rのセッションでlanguageserverをインストール
ダイアログが開いて言語を選択できるので「日本語」を設定する。
$R
> install.packages("languageserver")

５．拡張機能をVSCodeにインストール

６．VSCodeでRのパスを設定
Settingsを開いて、Rのインストールパスを設定する

７．VSCodeで挙動確認
Rのプログラムを実行して、プログラムが動くこと、グラフが表示されることを確認する

Win32APIでDrag＆Dropしたファイルをある場所にコピーする方法

2022-04-18T17:53:40+09:00

Win32APIでDrag＆Dropしたファイルをある場所にコピーする方法

1.宣言

#include "Shlwapi.h"
// Shlwapi.hの関数を使用するために下記の追加が必要
#pragma comment (lib, "Shlwapi.lib")

2.実処理

    UINT n;
    UINT i;
    UINT ret;
    TCHAR pszBuff[MAX_PATH * 10] = {};
    TCHAR pszNewFile[MAX_PATH * 10] = { _T("\\\\wsl$\\Arch\\mnt\\wsl\\share")};

    n = DragQueryFileA((HDROP)wParam, -1, NULL, 0);
    for (i = 0; i < n; i++) {
        ret = DragQueryFile((HDROP)wParam, i, pszBuff, MAX_PATH * 10);
        if (ret == -1) continue;

        LPWSTR fileName = PathFindFileNameW(pszBuff);
        wsprintf(pszNewFile, L"%s\\%s", pszNewFile, fileName);

        // 第３引数がFalseなので、コピー先に同名ファイルがあった場合は上書保存
        // TRUEにした場合は、失敗してエラーになる
        CopyFile(pszBuff, pszNewFile, FALSE);
    }

Drag＆Dropしたファイルを、WSL2のマウントフォルダに格納するようにした。
Shlwapi.hの関数は「PathFindFileNameW」。
ヘッダをincludeしただけだと、「未定義の関数」としてビルド時にエラーになる。
「#pragma comment (lib, "Shlwapi.lib")」を追記すると、Shlwapi.libをプロジェクトに参照追加しなくても動作するようになる。
理由がわかっていないので調査したい。

「PathFindFileNameW(pszBuff)」を実行して取得できるのは「xxxx.txt」のようなファイル名部分となる。
「PathFindFileNameW」を使用しているのは、TCHARを使用しているから。
CHARを使用する場合はたぶん「PathFindFileNameA」を使用するんだと思う。

「wsprintf(pszNewFile, L"%s\%s", pszNewFile, fileName);」で、変数pszNewFileにコピー先のpathと取得したファイル名を連結している。

WinSCPのコマンドを使ったbatでファイルを取得するサンプル

2022-03-15T23:44:55+09:00

WinSCPのコマンドを使って、ファイルを取得するbatのサンプルは下記。

目的：
指定した日付以降のファイルをダウンロードしたい

引数：
１．パスワード
２．IPアドレス（IPアドレスが固定じゃない場合用）
３．目的の「指定した日付」に該当する年月日（フォーマット：MM/DD/YY）

rem 引数の設定
set password=%1
set addr=%2
set date=%3

rem 保存したセッション情報を使用する場合
rem set remoteSession="保存したセッション名"

rem 実行ファイル
set WinSCP="実行ファイルパス\WinSCP.com"

rem 実行するスクリプト
set scriptFile="スクリプトファイルパス\scriptFile.txt"

rem ダウンロード用フォルダ
set downloadFolder=ダウンロードフォルダパス

rem ダウンロード用一時フォルダ
set tempFolder=temp
set tempPath=%downloadFolder%%tempFolder%\

cd /d %downloadFolder%

rem 一時フォルダがない場合は作成する
if not exist %tempFolder% mkdir %tempFolder%

rem 保存したセッション情報を使用する場合
rem echo open %remoteSession% > %scriptFile%

rem SCPでセッションopen
echo open scp://ユーザー名:%password%@%addr%:22 > %scriptFile%

echo cd ダウンロードするファイルパス >> %scriptFile%

rem バイナリモードに変更
echo option transfer binary

rem ダウンロード
echo get ./* %tempPath%  >> %scriptFile%

rem セッションクローズ
echo close >> %scriptFile%

rem WinSCPのコンソールをclose
echo exit >> %scriptFile%

rem スクリプトファイルを実行
@%WinSCP% /script=%scriptFile%

rem xcopyで対象日付以降のファイルをダウンロードフォルダに移動
xcopy /Y /D:%date% %tempPath%\* %downloadFolder%

rem 一時フォルダを削除
rmdir /s /q %tempFolder%

cd ../

callコマンドで、findを使った指定した更新日付以降の取得結果を絞り込めるかと思ったけれど、下記のようにした場合、【get 抽出したファイルのダウンロード】の部分は、callで実行されるリモート側のシェルコマンド扱いなので、get をWinSCPのコマンドとして認識してくれない。当然かもしれないけれど。

call 【指定した更新日付以降のファイルの抽出】 | 【get 抽出したファイルのダウンロード】

そうすると、ファイルを選別してダウンロードするためには、以下の方法になりそう。

１．callでダウンロードファイルを選別して、リネーム、もしくは一時ディレクトリにコピーしてからgetでダウンロード。ダウンロード後に一時ディレクトリは削除。

２．ダウンロード後にファイルを選別し、不要なファイルを削除。

上記だと２．の手段のほうが、リモートファイルを操作しないから安全かも。
他に方法あるのかなぁ。

WSL2（Arch）でsystemctlを使用できるようにするために行ったこと

2022-03-13T18:31:26+09:00

環境：
WSL＝WSL2
ディストリビューション＝Arch

TeraTarmでSSH接続をしたかったけれど、デフォルトではsystemctlが実行できないようだったので、設定を行った。

【使用したもの】
Distrod

【設定方法】
動いていたArchに入れたので、下記のページのOption2を実行
Option 2: Make your Current Distro Run Systemd

★実行内容
手順１：記載されている通りに実施
手順２：下記のほうを実行
/opt/distrod/bin/distrod enable
手順3は実行してもエラーとなっただけだった。

【実行後】
systemctl が利用できるようになっていて、daemonの再起動などもできるようになった。
便利。

Pythonのunittest実行時に、「ResourceWarning: unclosed file」が発生する場合の対処方法

2022-03-13T17:19:46+09:00

Pythonでunittestを実行していた際に、「ResourceWarning: unclosed file」が出力されたので、その対処方法について、記載。

global logins
def log_setting(log_level):
    global logins
    home = '<ログファイルパス>'
    pid = os.getpid()

    # create logger
    logins = logging.getLogger(__name__)
    logins.setLevel(logging.DEBUG)

    # create File Handler
    fh = logging.FileHandler('{0}/log/log{1}.log'.format(home, pid))
    fh.setLevel(logging.INFO)

    # create Formatter
    fh_formatter = \
        logging.Formatter(
            '%(asctime)s - %(levelname)s - \
            %(filename)s - %(name)s - %(funcName)s - %(message)s')

    # set Formatter
    fh.setFormatter(fh_formatter)

    # add Handler
    logins.addHandler(fh)

    # test logging
    logins.info('logtest:addHandler')

↑みたいな関数があり、unittest側からは下記でテストメソッド単位で呼び出したとする。

def setUp(self):
   logtest.log_setting(logging.DEBUG)`


def tearDown(self):
   logtest.logins.handlers = []

この場合、unittestを実行すると、ログファイル内に「ResourceWarning: unclosed file」が出力される。
理由はログファイルがクローズされていない状態で、ハンドラをクリアしているから。
ハンドラをクリアしている理由は、そうしないとテストメソッドの実行の都度、「log_setting」が呼び出されてハンドラが追加され、ログが重複して出力されてしまうから。

ログファイルをクローズする処理を入れればいいので、下記のようにする。

def tearDown(self):
   logtest.logins.handlers[0].close()
   logtest.logins.handlers = []

こうすると、ログファイルをクローズした後にハンドラをクリアするので、警告は出力されない。
ログも重複しない。

本当にいいのは、テスト対象側のプログラムを修正することだと思う。
ファイル出力しかしない想定であれば、addHandlerを使う必要はなく、下記で対応ができる。↓のほうがコード短いし、↑よりもいいかな。

```
def log_setting(log_level):
global logins
home = '/home/aoiro/work/logtest'
pid = os.getpid()

# create logger
logins = logging.getLogger(__name__)

log_format = \
    '%(asctime)s - {} - %(levelname)s - %(message)s'.format("tester")
logging.basicConfig(
    filename='{0}/log/log{1}.log'.format(home, pid),
    level=log_level, format=log_format)

```

Azure Pipelineを使ってリリースする場合の構成の検討

2021-12-05T22:37:31+09:00

Azure Pipelineを使った場合の利点の１つに、リリースするARMテンプレートにはないリソースを削除するところまで自動化できる、という点があると思う。
カスタムデプロイを使用した場合、リソースの差分は手動で削除しないといけないし、完全デプロイをコマンドラインから実行すると、リソースグループ単位で再構成される（確か）
なので、きれいにリリースができるのはとてもいい。

で、じゃあリリースに失敗しても綺麗に戻せるね、って考えたときに、どこから戻す？

本番ADFはライブモードで運用するから、戻すといったらARMテンプレートになるけど、カスタムデプロイは前述のように差分が残る
なので、開発ADF（もしくは検証用ADF）から戻すことになる

開発ADFのブランチ構成は、基本的に以下のようになる
・adf_publish：ライブモードの環境
・main：プルリクエストで反映、adf_publishへ発行用
・work：作業用

adf_publishの内容をリリースする、とした場合、流れは以下
work→（プルリクエスト）→main→（発行）→adf_publish→（Azure Pipeline）→本番ADF

戻そう、とした場合、本番ADFの状態をどこかに保持しておかないといけない
そうした場合、adf_publshに保存用のブランチを作成しておくほうが無難なんだろうか

work→（プルリクエスト）→main→（発行）→adf_publish→（Azure Pipeline）→本番ADF
　　　　　　　　　　　　　　　　　　　　　　　∟yyyymmdd_release

上のような構成にしておいて、本番ADFへの反映で失敗したら、yyyymmdd_releaseブランチから戻す
でも、Azure Pipelineのリリースは、Artifactsが必要で、Artifactsは手動実行できない
退避しているブランチに変更入れるわけにはいかない

そうなると、ブランチはmainに作成したほうがいいんだろうか

work→（プルリクエスト）→main→（発行）→adf_publish→（Azure Pipeline）→本番ADF
　　　　　　　　　　　　　　∟yyyymmdd_release

mainはプルリクエストで変更分をいろいろマージすると思うけど、リリースタイミングでブランチを切っておいて、失敗したらリリースタイミングのブランチで戻して、adf_publishに発行して、本番ADFに反映
いまいちな気がする

work→（プルリクエスト）→main→（発行）→adf_publish→（Azure Pipeline）→本番ADF
　　　　　　　　　　　　　　　　　　　　　　　∟yyyymmdd_release
↑の構成にして、リリース物件に更新用のreadmeを格納して、そこを更新して戻す、のほうがよさそう
readmeを更新した際のコミットコメントは「リリースに失敗したため、戻し作業を実施」とか？
ちょっとカッコ悪いかな

Azure Pipelineを使ったリリースの実施方法２

2021-12-04T23:58:56+09:00

Azure Pipelineでリリースした際に、増分リリースだと名称変更などした場合に反映先ADFにリソースが残ってしまうので、その対処方法について確認。

◆前提
増分リリース

◆前準備
・デプロイ前後に実行するスクリプトの準備
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-sample-script#pre--and-post-deployment-script
上記をそのままコピーして、反映元のブランチにPowerShellスクリプトとして保存する
トリガーの停止も組み込まれているので別途用意する必要はない
デプロイ前、デプロイ後の処理も、スクリプト実行時の引数で切り分けて実行するようになっている

◆手順
１．ジョブの追加
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-sample-script#script-execution-and-parameters
リリースの前後に、PowerShellを実行するジョブを追加する
デプロイ前のジョブのScript Argumentsには下記を設定する

-armTemplate "$(System.DefaultWorkingDirectory)/" -ResourceGroupName  -DataFactoryName  -predeployment $true -deleteDeployment $false

デプロイ後のジョブのScript Argumentsには下記を設定する

-armTemplate "$(System.DefaultWorkingDirectory)/" -ResourceGroupName  -DataFactoryName  -predeployment $false -deleteDeployment $true

下記のような感じになる

２．保存して動作確認

★注意
トリガーを削除して同じ名前で異なる種類のトリガーを作成したら、リリースでエラーが発生する
同名トリガーの型を更新できない、というエラーだった
TriggerTypeCannotUpdate: Trigger type cannot be updated.null

DataFactoryでトリガーを再作成しようとすると、一度トリガー削除→発行→再作成という手順をとらないといけないけど、Azure Pipelineでも同様らしい

↑スクリプトを修正して解決できた
対処方法は下記。

前準備で作成したスクリプトに下記を追加する
① $triggersToStartの下くらいに以下を追加
同名、かつ、テンプレート内と反映先でタイプの違うトリガーを取得

#Trigger reCreate
$triggersNameAndTypeInTemplate = $triggersInTemplate | ForEach-Object { 
    New-Object PSObject -Property @{
        Name = $_.name.Substring(37, $_.name.Length-40)
        TriggerType = $_.Properties.type
    }
}
$triggersToReCreate = $triggersToStop | ForEach-Object {
    foreach($entry in $triggersNameAndTypeInTemplate.GetEnumerator()) {
        if (($entry.Name -eq $_.Name) -and ($_.TriggerType -ne $entry.TriggerType)) {
            Write-Host "reCreate target trigger name " $_.Name
            New-Object PSObject -Property @{
                Name = $_.Name
                TriggerType = $_.TriggerType
            }
        }
    }
}

② if ($predeployment -eq $true) {}のブロックの中の、$triggersToStop | ForEach-Object {}のブロックの次に以下を追加

    #Delete reCreate trigger
    Write-Host "Deleting triggers for reCreate"
    $triggersToReCreate | ForEach-Object { 
        Write-Host "Deleting trigger "  $_.Name
        $trig = Get-AzDataFactoryV2Trigger -name $_.Name -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName
        if ($trig.RuntimeState -eq "Started") {
            if ($_.TriggerType -eq "BlobEventsTrigger" -or $_.TriggerType -eq "CustomEventsTrigger") {
                Write-Host "Unsubscribing trigger" $_.Name "from events"
                $status = Remove-AzDataFactoryV2TriggerSubscription -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.Name
                while ($status.Status -ne "Disabled"){
                    Start-Sleep -s 15
                    $status = Get-AzDataFactoryV2TriggerSubscriptionStatus -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.Name
                }
            }
            Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.Name -Force 
        }
        Remove-AzDataFactoryV2Trigger -Name $_.Name -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Force 
    }

Azure Pipelineを使ったリリースの実施方法１

2021-12-04T14:24:27+09:00

Azure Pipeline使って別のDataFactoryへのリリースをやってみたので、備忘録。
記載するのはAzure Pipelineを使ったリリースまでで、トリガーの設定変更や、削除したリソースの反映までは行っていない

実行したのは下記なので、それぞれ手順を記載
・mainブランチに変更が入った場合にトリガー起動でリリース
・adf_publishへの発行をトリガーとしてリリース

◆前提
増分デプロイ

◆使ったDataFactory
開発ADF：作業用：DevOpsにコラボレーションブランチを作成済み
本番ADF：開発ADFのリリース先：ライブモード

◆前準備
１．開発ADFのコラボレーションブランチを作成しているプロジェクトにサービス接続を作成する
　プロジェクトは作成していたけど、サービス接続を作成してなかったからリリースを作成してもデプロイできなかった
https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/templates/deployment-tutorial-pipeline#create-a-devops-project
２．ブランチの役割を決めておく
　リリース先に反映するブランチを決めておく
　下記の構成で、mainブランチをデフォルトブランチにしてリリース設定をすると、workからのプルリクエストを許可した時点で本番ADFに反映される
　adf_publish：ライブモードの動作環境。mainブランチで発行することで、mainの内容が反映される
　mainブランチ：workの内容をプルリクエストでマージする先
　workブランチ：開発用

◆手順（mainブランチに変更が入った場合にトリガー起動でリリース）
１．ビルド用のパイプラインを作成する
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-improvements#create-an-azure-pipeline
　package.jsonの作成や場所は、リリース用のブランチのどこか
　公式のyamlの部分を作成環境に合わせて修正する
　$(Build.Repository.LocalPath)＝ブランチの/（ルート）に該当するので、ブランチの直下に格納する場合は記載不要
　ブランチの直下に「build」フォルダを作成した場合は、「build」と記載する。
　$(Build.Repository.LocalPath)はコンテナ内にチェックアウトされたリソースフォルダを指している

２．リリースを作成する
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-automate-azure-pipelines
上記の手順の「Azure Pipelines リリースをセットアップする」６．で、↑の１で作成したパイプラインを指定すると、トリガー起動するようになる（Source typeで「Build」を選択する）

「Azure Resource Manager connection」では、前準備で作成したサービス接続を選択する
前準備で作成したサービス接続を選択しないとサブスクリプションやリソースグループを選択できない

タスクを設定する際に選択するARMテンプレートは、リリースするブランチに格納してある、ARMTemplateForFactory.jsonと、ARMTemplateParametersForFactory.json
今回は開発ADF→本番ADFなので、「Override template parameters」でfactoryNameを上書きしている

３．保存して動作確認
問題なければ、デフォルトブランチに変更内容を反映することでリリースまで実行される

★注意点
１で作成したビルド用のパイプラインで出力されるARMテンプレートは、adf_publishに反映されない
なので、adf_publishに反映する場合は「発行」を押下する必要がある

◆手順（adf_publishへの発行をトリガーとしてリリース）
※「mainブランチに変更が入った場合にトリガー起動でリリース」１の手順は不要

１．リリースを作成する
参照：https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-delivery-automate-azure-pipelines
上記の手順の通りにSource typeで「Azure Repos Git」を選択する
Defult branchでadf_publishを選択する

２．トリガーを設定する
稲妻のアイコンを押下して、トリガーを設定する
今回はadf_pulishへの発行をトリガーにするので、Continuous deployment triggerを有効にして、Branchに「adf_publish」を選択する

３．リリースを作成する
「mainブランチに変更が入った場合にトリガー起動でリリース」２と同じ

４．保存して動作確認

クラスオブジェクトのシリアル化

2021-10-16T18:37:27+09:00

PythonでクラスオブジェクトをJsonに出力できると知ったので、メモ。

シリアル化、という手段で、通常はメモリに保持されるクラスオブジェクトを、バイナリ変換してファイル出力できるようにできるとのこと。
利点としては、プログラムが終わった後にクリアされてしまうクラスオブジェクトの情報を、ファイルやDBなどに保存しておくことができ、再作成の必要がなくなるという点。

復元する、他のプログラムと共有する、DBに保存しておいて呼び出す。
色々使い道がありそう。

Python でクラスオブジェクトをJSON形式にする・戻す

クラス内部で複数の変数を定義しておいて、クラスオブジェクトを生成して値を格納して、それをjsonでダンプしておけば、ある程度の長さならDBのString型カラム1つに保存することができて、後は必要に応じて呼び出して復元するっていうのもできるのか。
カラムに分けて格納してselectしてそれぞれ成形して…ってやるよりも楽かな。

クラスオブジェクトを保存する必要が無ければ、シリアル化は不要、ということになるのかな？
プログラム実行後に復元や、２回目以降に再利用する必要がなければ不要か。

例えば、データに対する処理が前回実行結果の一部を更新していくような場合、とか？
DBに格納した前回実行結果を取得して、CSVファイルから今回変更分を読み込んで、反映してデータを最新化して、DB登録、という流れの場合は採用できるかな。

１．DBに格納した前回実行結果を取得：selectの実行
　→dumpしたクラスオブジェクトをDBに保存していた場合、同様にselectを実行
　　ただ、jsonにダンプしていた場合は、デシリアライズすることでクラスインスタンスが復元される
　　DBからカラムでデータを取得した場合はクラスオブジェクトを生成して設定するところから始める

２．CSVファイルから今回変更分を読み込む
　→処理内容に違いはない

３．反映してデータを最新化
　→処理内容に違いはない

４．DB登録：insert（update）の実行
　→カラムに分けたデータか、クラスオブジェクトかの違い

この例だと大きな差は１くらい？
こういう時に有利！っていう状況ないかな。

Bitbucketの始め方（Googleアカウントを使用した場合）

2021-10-03T08:57:25+09:00

Bitbucketを使用した際に、cloneができなかったのでその対処方法を調べたら下記でできた。

BitbucketにGoogle認証している人はcloneためにパスワードを発行しましょう

Google認証とか、他のサービスと連携せずにアカウント作成した場合には、アカウント作成時のパスワードでcloneできるんだろうな...

上記でcloneできたものの、pushできなかったので、下記を参考に実施。
難しい…

bitbucketにpushできない

Azure Synapse Analyticsの覚書（2021/9/5）

2021-09-05T22:38:06+09:00

Azure Synapse Analyticsについて、覚えたことを記載。

Synapse Analyticsのメモリについて
データウェアハウスの容量設定

上記にあるように、DWU毎にサービスレベルが決まっている。
「データウェアハウスあたりのメモリ」はディストリビューションの総メモリサイズとなっている。
200DWUであれば、データウェアハウスあたりのメモリは120GBとなっていて、「コンピューティングごとの配布」が60となっている。
「コンピューティングごとの配布」に記載されている値は、データウェアハウスのディストリビューション数。
そのため、1ディストリビューションあたりのメモリサイズは2GBとなる。

動的リソースクラス
動的リソースクラス

Synapse Analyticsでは、ユーザーに動的にメモリを割り当てることができる。
最初のユーザー（管理者ユーザー）はsmallrcから変更できないため、smallrc以外のリソースクラスを割り当てる場合は、専用のユーザーを作成する必要がある。
xlargercを割り当てると、メモリの70%をユーザーの処理に使用する。
これは、1ディストリビューションあたりのメモリの割り当てなので、上記の例にならって、200DWUであれば、xlargercを割り当てられたユーザーが使用可能な最大メモリは、2GB×70％＝1.4GBとなる。多分。
リソースクラスの割り当ては課金対象ではないので、DWUを上げる前にリソースクラスの見直しをして、使用可能なメモリサイズを調整してからDWUを上げてもいいかもしれない。

メモリの見積もり
メモリ要件の見積もり方法

テーブルにデータ移行を行う場合は、上記からメモリの見積もりを行ったほうがよい。
数百カラムのテーブルのデータ移行を行う場合、列圧縮に必要なメモリが足りなくて、データ移行時にエラーが発生する可能性がある。

select-insertするstored procedureを作成する場合はSSMSから実行する。
Synapse Analytics Studioのクエリエディタからだと、select-insertを含むstored procedureのcreateがエラーになった。
SSMSからだと問題なく作成できたし、動作した。
バグ？

PowerShellで正規表現で対象行を抽出する方法

2021-09-05T21:34:35+09:00

PowerShellで特定の行を抽出する方法

小数点以下n桁以上の値を持つ行を出力するコマンド

$re ='[0-9]\.[0-9]{n,}'
select-string -path .\powershell.csv -pattern $re

出力結果は下記のようになる。
powershell.csv:8:1.0 110.0 10.0 1.899999999
powershell.csv:11:1.0 110.0 10.0 1.899999999

出力結果に含まれるファイル名部分を削除して、抽出した行のみ出力する方法

select-string powershell.csv -pattern $re  | foreach-object { $($_ -split ":" )[3] }

出力結果は下記のようになる。
1.0 110.0 10.0 1.899999999
1.0 110.0 10.0 1.899999999

クラウドサービスで構築する際のパラメータシート

2021-06-25T17:29:54+09:00

通常、ものを作るときにはパラメータシートが出てくる。
サーバーにOSをインストールするときも、バージョンはどうしますか、この設定はどうしますか、みたいにすごく細かくパラメータの設定項目が出てくる。

クラウドサービスのSynapse Analyticsとか、仮想マシンとかを使ってサービスを構築しようとしたときにも同じようにパラメータシートが出てくるのは、当然だと思う。
だけど、クラウドサービスって、1カ月で項目が追加されたり減ったりするから、パラメータシートを作るのがとても大変。
しかも選択肢ごとにパラメータが変わってくるから、どのパラメータを設定するか決めていない場合に、パラメータシートで全部対応するのが本当に大変。
時間をかけて作っても、数か月後には確実にどこか変わってるし。

パラメータシートを使わないとぶっつけ本番で構築することになるから、必要になるとは思うんだけど、その場合項目ってどうするのが正解なんだろう？
あらかじめ要望を聞いて、これを使うだろうっていう想定の項目だけ記載したパラメータシートを展開するんだろうか。

パラメータシート作成したくないなぁ。
下手したら次の日とか翌週には変わってるかもしれなくて、それを最新化して保守していかないといけないとか、無駄が過ぎる気がするんだよなぁ。

クラウドサービスのそういう構築用資料の作成と保守ってどうしてるんだろう。

WSLのディストリビューションの格納場所の移動

2020-12-26T16:32:04+09:00

WSLでUbuntuをインストールしたものの、Cドライブの容量が心元なかったため、ディレクトリ移動した際の手順を記述します。
``

◆手順

１．ディストリビューションをtarファイルにエクスポート

wsl --export Ubuntu-20.04 F:\Work\wsl\Ubuntu-20.04.tar

２．ディストリビューションの削除

wsl --unregister Ubuntu-20.04

３．ディストリビューションのインポート

wsl --import Ubuntu-20.04 F:\Work\wsl\Ubuntu20.04 F:\Work\wsl\Ubuntu-20.04.tar

構文：
wsl --import ＜ディストリ名＞＜インストールディレクトリパス＞＜１でエクスポートしたtar＞
※ ディストリ名は任意でいいらしい

思ったよりすごく簡単にできた。
３．でディストリ名を任意で設定できるということは、コピーしてディストリ名を別にすれば環境の複製もできるんだろうなぁ。

Azure プライベートエンドポイント

2020-11-22T15:15:09+09:00

プライベートエンドポイント

プライベートエンドポイントは、作成した仮想ネットワーク内のプライベートDNSゾーンと統合可能な、プライベートIPアドレス。
作成すると、対象仮想ネットワークのアドレス範囲内でIPアドレスが付与され、対象仮想ネットワーク内のリソースは、プライベートエンドポイントが指すリソースへ、DNS名で接続が可能となる。
サービスエンドポイントの場合は許可されたサブネット範囲となっていたが、プライベートエンドポイントはNSGなどの設定も無視して、対象仮想ネットワーク内全般からアクセスが可能。

以下のような構成を考える。

仮想ネットワーク：vnet-main
- サブネット：subnet-001
  - 仮想マシン：vm-001
  - NIC：nic-001
  - NSG：nsg-001 ※storage-Aへのアウトバウンドを拒否
- サブネット：subnet-002
  - 仮想マシン：vm-002
  - NIC：nic-002
  - NSG：nsg-002
ストレージアカウント：storage-A

storage-Aのプライベートエンドポイントをvnet-mainに作成すると、vm-001、vm-002はstorage-Aにアクセスができる。
vm-001はNSGで拒否となっているが、プライベートエンドポイントでは無効となる。
プライベートエンドポイントを設定したリソースがパブリックアクセスを拒否するかは、そのリソースの接続しだいとなる点はサービスエンドポイントと同じ。

サービスエンドポイントとの違いは、対象の仮想ネットワーク内のリソースに対してアクセス制御を行えない点。

不明点

上記のvnet-mainの他に、仮想ネットワークvnet-subが存在し、storage-Aがパブリックアクセスを拒否していた場合、vnet-sub内のリソースがstorage-Aにアクセスするためには、vnet-sub内にもプライベートエンドポイントを作成する必要があるのか？もしくは、プライベートリンクサービスを使用するのか？

「Azure プライベートエンドポイントとは」
https://docs.microsoft.com/ja-jp/azure/private-link/private-endpoint-overview

プライベートエンドポイントの利点と使いどころがいまいち...。オンプレとの接続か、プライベートリンクサービスを使うとき以外はあまり使わないものなのか？

Azure サービスエンドポイント

2020-11-22T14:50:02+09:00

サービスエンドポイント

サービスエンドポイントは、ストレージアカウント、SQL Databaseなどのサービスに対して、接続を制限するための機能。
サブネットに統合される。
サービスタグ（Microsoft.SQLなど）があらかじめ設定されていて、サブネットやネットワークインターフェースに対して設定が可能。

以下のような環境を考える。

仮想ネットワーク：vnet-main
- サブネット001：subnet-001
  - 仮想マシン：vm-001
  - NIC：nic-001
  - NSG：nsg-001
- サブネット002：subnet-002
  - 仮想マシン：vm-002
  - NIC：nic-002
  - NSG：nsg-002
- サブネット003：subnet-003
  - 仮想マシン：vm-003
  - NIC：nic-003
  - NSG：nsg-003
ストレージアカウント：storage-A

subnet-001、subnet--002のサービスエンドポイントに「Microsoft.Storage」と設定する。

　1. storage-Aが何も接続設定をしていない場合
　　仮想マシンvm-001、vm-002、vm-003はstorage-Aに接続できる
　　ストレージアカウントは基本的に仮想ネットワーク内、およびインターネットからのアクセスを拒否しないため
　　このとき、vm-001とvm-002はプライベートアクセス、vm-003はパブリックアクセスとなっている

　2. storage-Aがsubnet-002にのみ接続可にしていた場合
　　仮想マシンvm-001、vm-003は接続できず、vm-002は接続ができる
　　vm-001はstorage-Aの接続設定で接続が拒否される
　　vm-003はサービスタグが設定されていないため、パブリックアクセスを行おうとして拒否される

サービスエンドポイントを使用した接続は、プライベートIPを使用したプライベートアクセスとなる。
対象の仮想ネットワーク内のアドレス範囲で決定されたプライベートIPアドレスを使用して接続が行われる。
それ以外のアクセスはパブリックアクセスとなる。

サービスエンドポイントの利点としては以下。

インターネットや関係のないサブネット内のリソースからのアクセスを制御できる
プライベート接続になるので、セキュリティ面で安全

「仮想ネットワークサービスエンドポイント」
https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-service-endpoints-overview