GitHubじゃ!Pythonじゃ!

GitHubからPython関係の優良リポジトリを探したかったのじゃー、でも英語は出来ないから日本語で読むのじゃー、英語社会世知辛いのじゃー

wal-e

wal-e – Postgresのための継続的なアーカイブ

投稿日:

Postgresのための継続的なアーカイブ

WAL-E

Postgresのための継続的なアーカイブ

WAL-Eは、PostgreSQL WALファイルとベースバックアップの連続アーカイブを実行するように設計されたプログラムです。

WAL-Eの使用や対応に協力するには、 wal-e@googlegroups.comアーカイブとサブスクリプション設定 )のメーリングリストにメールを送信することを躊躇しないでください。 Githubの問題は現在、既知の問題を追跡するために使用されているので、それらを提出することをお気軽に。

インストール

最新のパッケージがパッケージマネージャーから入手できない場合、このコマンドはほとんどのオペレーティングシステムで動作します:

sudo python3 -m pip install wal-e[aws,azure,google,swift]

上記のリストから使用しないストレージサービスは省略できます。

主なコマンド

WAL-Eには次のキーコマンドがあります:

  • バックアップを取る
  • バックアッププッシュ
  • ウォールフェッチ
  • ウォールプッシュ
  • 削除

これらの演算子はすべて、WAL-Eが読み込むいくつかの環境変数のコンテキストで動作します。 設定される変数は、使用されているストレージプロバイダによって異なります。詳細は以下のとおりです。

WAL-Eの体系化コンセプトはPREFIXです。 プレフィックスは、各書き込みデータベースごとに一意に設定し、特定のデータベースに格納されているすべてのオブジェクトに接頭辞を付ける必要があります。 次に例を示しますs3://bucket/databasename

これらのうち、 “プッシュ”演算子はバックアップデータをストレージに送り、 “フェッチ”演算子はストレージからバックアップデータを取得します。

walコマンドは、Postgresのarchive_commandrestore_commandによって呼び出されて先読みログを取得またはプルします。また、 backupコマンドは、WALセグメントを適用できるベースデータベースのホットバックアップを取得またはプッシュするために使用されます。 最後に、 deleteコマンドを使用して、有限数のバックアップを保持するようにアーカイブをプルーニングします。

AWS S3およびWork-alikes

  • WALE_S3_PREFIX(例: s3://bucket/path/optionallymorepath
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_REGION(例: us-east-1

オプション:

  • WALE_S3_ENDPOINT: S3エンドポイントの手動指定を参照
  • AWS_SECURITY_TOKEN:AWS STSを使用する場合
  • --aws-instance-profile--aws-instance-profileて、インスタンスプロファイルから資格を収集します。 「AWS IAMインスタンスプロファイルの使用」を参照してください。

アズールブロブストア

以下の例は、リソースグループresgroup内のAzureの次のblobストレージに基づいていますresgroup : resgroup

  • WALE_WABS_PREFIX(例: wabs://container1/nextpath
  • WABS_ACCOUNT_NAME(例: store1
  • WABS_ACCESS_KEY( azure storage account keys list store1 --resource-group resgroup実行するとkey1を使用します) azure storage account keys list store1 --resource-group resgroupが機能するにはAzure CLIがインストールされている必要があります。
  • WABS_SAS_TOKEN(WABS_ACCESS_KEYを指定していない場合にのみ必要です)

Googleストレージ

  • WALE_GS_PREFIX(例: gs://bucket/path/optionallymorepath
  • GOOGLE_APPLICATION_CREDENTIALS

迅速

  • WALE_SWIFT_PREFIX(例: swift://container/path/optionallymorepath
  • SWIFT_AUTHURL
  • SWIFT_TENANT
  • SWIFT_USER
  • SWIFT_PASSWORD

オプションの変数:

  • SWIFT_AUTH_VERSIONデフォルトは2です。 Softlayerなどのオブジェクトストアにはバージョン1必要です。
  • SWIFT_ENDPOINT_TYPEのデフォルトはpublicURL 、内部ネットワークを使用するためにRackspace Cloud FilesなどのオブジェクトストアのinternalURLに設定することができます。

ファイルシステム

  • WALE_FILE_PREFIX(例: file://localhost/backups/pg

重要

すべての書き込みサーバーに異なる_PREFIXが設定されていることを確認してください。 2つの間で値を再利用すると、データベースを書き込む際に回復不能なバックアップが発生する可能性があります。

依存関係

  • Python(> = 3.4)
  • lzop
  • psql(> = 8.4)
  • pv

このソフトウェアにはPythonの依存関係もあります: pipインストールすると、それを解決しようとします:

  • gevent> = 1.1.1
  • boto> = 2.40.0
  • 紺青= 1.0.3
  • google-cloud-storage> = 1.4.0
  • python-swiftclient> = 3.0.0
  • python-keystoneclient> = 3.0.0

バックエンドストレージの依存関係がインストールされていなくても、WAL-Eを使用することができます。これらのインポートは、ストレージ構成で使用する必要がある場合にのみ実行されます。

基本バックアップをS3にプッシュする:

$ AWS_SECRET_ACCESS_KEY=... wal-e                     \
  -k AWS_ACCESS_KEY_ID                                \
  --s3-prefix=s3://some-bucket/directory/or/whatever  \
  backup-push /var/lib/my/database

WALセグメントをWABSに送信する:

$ WABS_ACCESS_KEY=... wal-e                                   \
  -a WABS_ACCOUNT_NAME                                        \
  --wabs-prefix=wabs://some-bucket/directory/or/whatever      \
  wal-push /var/lib/my/database/pg_xlog/WAL_SEGMENT_LONG_HEX

基本バックアップをSwiftにプッシュする:

$ WALE_SWIFT_PREFIX="swift://my_container_name"              \
  SWIFT_AUTHURL="http://my_keystone_url/v2.0/"               \
  SWIFT_TENANT="my_tennant"                                  \
  SWIFT_USER="my_user"                                       \
  SWIFT_PASSWORD="my_password" wal-e                         \
  backup-push /var/lib/my/database

Google Cloud Storageに基本バックアップをプッシュする:

$ WALE_GS_PREFIX="gs://some-bucket/directory-or-whatever"     \
  GOOGLE_APPLICATION_CREDENTIALS=...                          \
  wal-e backup-push /var/lib/my/database

WAL-Eで何らかの環境変数管理を使用することが一般的に推奨されています。この方法は、冗長ではなく、エラーの発生が少なく、ログに秘密情報を公開する可能性は低いです。

envdirdaemontoolsパッケージの一部は、環境変数を設定するための推奨されるアプローチの1つです。 envdirと互換性のあるディレクトリを用意することができます:

# Assumption: the group is trusted to read secret information
# S3 Setup
$ umask u=rwx,g=rx,o=
$ mkdir -p /etc/wal-e.d/env
$ echo "secret-key-content" > /etc/wal-e.d/env/AWS_SECRET_ACCESS_KEY
$ echo "access-key" > /etc/wal-e.d/env/AWS_ACCESS_KEY_ID
$ echo 's3://some-bucket/directory/or/whatever' > \
  /etc/wal-e.d/env/WALE_S3_PREFIX
$ chown -R root:postgres /etc/wal-e.d


# Assumption: the group is trusted to read secret information
# WABS Setup
$ umask u=rwx,g=rx,o=
$ mkdir -p /etc/wal-e.d/env
$ echo "secret-key-content" > /etc/wal-e.d/env/WABS_ACCESS_KEY
$ echo "access-key" > /etc/wal-e.d/env/WABS_ACCOUNT_NAME
$ echo 'wabs://some-container/directory/or/whatever' > \
  /etc/wal-e.d/env/WALE_WABS_PREFIX
$ chown -R root:postgres /etc/wal-e.d

この準備をした後、間違った値を誤って使用するリスクを減らして、WAL-Eコマンドをはるかに簡単に実行することができます。

$ envdir /etc/wal-e.d/env wal-e backup-push ...
$ envdir /etc/wal-e.d/env wal-e wal-push ...

envdirはPostgreSQLで使用されるarchive_command機能と組み合わせて、継続的なアーカイブを可能にします。 継続的なアーカイブを可能にするには、 postgresql.confを編集してサーバを再起動する必要があります。 継続的なアーカイブを可能にする重要な設定は、ここでは関連しています。

wal_level = archive # hot_standby and logical in 9.x is also acceptable
archive_mode = on
archive_command = 'envdir /etc/wal-e.d/env wal-e wal-push %p'
archive_timeout = 60

アーカイブされたすべてのセグメントは、PostgreSQLのログに記録されます。

警告

PostgreSQLユーザは、pg_settingsテーブルを確認し、採用されたarchive_commandを見ることができます。 その理由から秘密の情報をpostgresql.confに入れないでください。代わりにenvdirを使用してください。

ベースバックアップ( backup-push )はいつでもアップロードできますが、リストアを実行するには少なくとも1回は実行する必要があります。 WALセグメントのアーカイブをスキップすることを決定した場合は、再度実行する必要があります。保存されたWALセグメントにギャップがあれば複製を続行できません。

主なコマンド

backup-pushbackup-fetchwal-pushwal-fetchはWAL-Eの主要機能を表し、データベースマシン上に存在する必要があります。 上記のように機能するwal-pushコマンドとwal-fetchコマンドとは異なり、 backup-pushbackup-fetchは少し説明が必要です。

バックアッププッシュ

デフォルトでは、 backup-pushはすべてのユーザー定義の表領域をデータベース・バックアップに含めます。 WAL-Eの表領域の復元動作については、以下のbackup-fetchセクションを参照してください。

バックアップを取る

backup-fetchを使用して、ストレージからベースバックアップを復元します。

このコマンドは、 LATEST pseudo-backup-nameを使用して、ダウンロードするバックアップを検索します。

$ envdir /etc/wal-e.d/fetch-env wal-e               \
--s3-prefix=s3://some-bucket/directory/or/whatever  \
backup-fetch /var/lib/my/database LATEST

また、 backup-list示されているbackup-listを指定することもできます。これは、特定時点のリカバリのために古いバックアップをリストアする場合に便利です。

$ envdir /etc/wal-e.d/fetch-env wal-e               \
--s3-prefix=s3://some-bucket/directory/or/whatever  \
backup-fetch                                        \
/var/lib/my/database base_LONGWALNUMBER_POSITION_NUMBER

バックアップに関連するWALセグメントを回復するためにrecovery.confファイルを提供する必要があります。 要するに、 recovery.confはPostgresのデータディレクトリに以下のような内容で作成する必要があります:

restore_command = 'envdir /etc/wal-e.d/env wal-e wal-fetch %f %p'
standby_mode = on

このようなrecovery.confが設定されたデータベースは、WAL用のWAL-Eストレージを無期限にポーリングします。 pg_ctl promoteを実行すると、リカバリを終了できます。

Point In Time Recovery(PITR)を実行したい場合、 recovery.confにrecovery targetを追加することができます。

recovery_target_time = '2017-02-01 19:58:55'

リカバリターゲットを指定するには、トランザクションIDなどの他にもいくつかの方法があります。

リカバリターゲットに関係なく、デフォルトでPostgresはこの時点でリカバリを一時停止し、プロモーション前に検査を許可します。 目標基準に達したときの動作をカスタマイズする方法の詳細については、 回復ターゲットを参照してください。

表スペースのサポート

表スペースを使用している場合にのみ、 backup-fetch実行方法に関する追加の問題を考慮する必要があります。 オプションは次のとおりです。

  • ユーザー主導の復元

    WAL-Eは、 backup-fetch実行される前にテーブルスペースのシンボリックリンクが配置されることを期待しています。 これは、リストア時間の前に${PG_CLUSTER_DIRECTORY}/pg_tblspcに必要なすべてのシンボリックリンクが含まれていることを保証することで、ターゲットパスを準備することを意味します。 予想されるシンボリックリンクが存在しない場合、 backup-fetchは失敗します。

  • ブラインドリストア

    backup-fetchを実行する前に表スペース・ストレージ構造を再現できない場合は、オプション・フラグ--blind-restore設定できます。 これにより、WAL-Eはシンボリックリンク検証プロセスをスキップし、すべてのデータを${PG_CLUSTER_DIRECTORY}/pg_tblspcパスに直接${PG_CLUSTER_DIRECTORY}/pg_tblspcます。

  • 修復仕様

    backup-fetch --restore-spec RESTORE_SPECオプションを使用して、WAL-Eに復元仕様ファイルを提供することができます。 この仕様は有効なJSONでなければならず、必要なターゲットストレージパスだけでなく、すべての含まれているテーブルスペースを含んでいなければならず、シンボリックリンクpostgresはテーブルスペースを想定しています。 単一の表領域を持つクラスタの例を次に示します。

    {
        "12345": {
            "loc": "/data/postgres/tablespaces/tblspc001/",
            "link": "pg_tblspc/12345"
        },
        "tablespaces": [
            "12345"
        ],
    }
    

    この情報が与えられれば、WAL-Eはデータストレージディレクトリを作成し、それを${PG_CLUSTER_DIRECTORY}/pg_tblspc適切にシンボリックリンクします。

警告

リストア仕様の表領域の"link"プロパティには、 pg_tblspc接頭辞が含まれている必要があります。追加されません。

補助コマンド

これらは、バックアップまたはWALのプッシュおよびフェッチには明示的に使用されないコマンドですが、WAL-Eアーカイブされたデータベースの監視またはメンテナンスにとって重要です。 これらのコマンドは、適切な_PREFIXセットを持つ任意のコンピュータから生産的に実行することができます。また、データベース・マシン上に存在しなければならないバックアップ( backup-pushbackup-fetchwal-pushwal-fetch )データを操作または読み取るために必要な資格情報

バックアップリスト

backup-listは、指定されたWAL-Eコンテキストに対して完了した基本バックアップのリストに役立ちます。 一部のフィールドは、 --detailオプションがbackup-list [1]に渡されたときにのみ入力されます。

注意

--detailのみのフィールドは厳密には必須ではないフィールドの右側にはありません--detailは渡されます。 空の列を示すためにCSV解析ライブラリ(2つのタブ区切り文字が出力されるため)を使用する場合は問題はありませんが、文字列のマングリングを使用してフィールドを抽出したい場合は注意してください。

まず、 --detailが渡されたかどうかにかかわらず埋められるフィールド:

CSVのヘッダー 意味
バックアップの名前。これは、 deleteコマンドとbackup-fetchコマンドに渡すことができます。
最終更新日 バックアップが完了してアップロードされた日時。タイムゾーン情報を含むISO互換形式でレンダリングされます。
wal_segment_backup_start ウォールセグメント番号。 これは24文字の16進数です。 この情報は、さまざまなバックアップのタイムラインと相対的な順序を示します。
wal_segment_offset_backup_start このバックアップが開始するWALセグメント内のオフセット。 これは主に、同じWALセグメントで開始されるバックアップの場合のあいまいさを避けるためです。

第2に、 --detailが渡されたときにのみ入力されるフィールド:

CSVのヘッダー 意味
expanded_size_bytes バックアップの圧縮解除されたサイズ(バイト単位)。
wal_segment_backup_stop このバックアップを一貫性のある状態にするために必要な最後のWALセグメントファイル。したがって、ホットスタンバイで使用できます。
wal_segment_offset_backup_stop このバックアップを一貫性のある状態にするために必要な最後のWALセグメントファイル内のオフセット。
[1] backup-list --detailは、 backup-list --detailよりも遅い(1回のWebリクエストが1回のWebリクエストではなく、1回のWebリクエストではなく、1回のWebリクエスト)ので、通常のbackup-list情報はすべて1つの必要性です。

削除

deleteは、さまざまな理由でストレージからデータを削除するために使用される追加のサブコマンドが含まれています。 これらのコマンドは、 deleteサブコマンド自体が--confirmような削除を行うサブコマンドに適用されるオプションをとるため、別々に編成され--confirm

すべての削除は、再入可能であり、冪等であるように設計されています。一度に複数の削除を実行する場合、または同じ削除コマンドを複数回再送信する場合、他の削除を取り消すかどうかにかかわらず、

これらのコマンドには、デフォルトのdry-runモードがあります。 このコマンドは、オペレータのエラーを避けるために非常に特殊な状況を除いてデータを削除しないように基本的に最適化されています。 dry-runを実行すると、 wal-eはdry-runモードで実行されていなかった場合に削除されるすべてのキーと、実際には何も削除されなかったことを示すすべてのキーのヒント行を報告します格納。

実際にデータを削除するには、削除するには--confirmを渡す必要があります。 --dry-run--confirm両方を--dry-runと、渡されたオプションの順序にかかわらず、 --confirm実行されます。

現在、これらの種類の削除がサポートされています。 分かりやすくするために環境変数設定を省略した例:

  • before :指定したベースバックアップ名の前に、すべてのバックアップとウォールセグメントファイルを削除します。 これには、渡された基本バックアップは含まれません。実行可能なバックアップのままです。

    例:

    $ wal-e delete [--confirm] before base_00000004000002DF000000A6_03626144
    
  • retain :指定した数のバックアップをretain残し、それより古いすべてのベースバックアップとウォールセグメントファイルを削除します。

    例:

    $ wal-e delete [--confirm] retain 5
    
  • old-versions :古いフォーマットのすべてのバックアップおよびウォールファイルセグメントを削除します。 これは、主要なWAL-Eバージョンのアップグレードとそれに続く基本バックアップの後に実行することを目的としています。 最初にベースバックアップが正常に実行されなかった場合は、ベースバックアップを実行するまでデータ損失にさらされます。

    例:

    $ wal-e delete [--confirm] old-versions
    
  • everything :コンテキスト内のすべてのバックアップおよびウォールファイルセグメントを削除します。 これは、データベースを廃止し、アーカイブを必要としない場合に適しています。

    例:

    $ wal-e delete [--confirm] everything
    

圧縮ファイルと一時ファイル

ストレージにプッシュされたすべてのアセットは、非常に高速なlzo圧縮アルゴリズムを使用してオブジェクトを圧縮するプログラム “lzop”によって実行されます。 ギガバイトを圧縮するのにおよそ2秒のCPU秒がかかります。約25MB / sでストレージに送信する場合、CPU時間は約5%です。 圧縮率は、ほとんどの場合、元のファイルサイズの50%以下にすることが期待されているため、バックアップと復元はかなり高速になります。

ストレージサービスでは、一般に、ストアドオブジェクトのContent-Lengthヘッダを前面に設定する必要があるため、入力ファイル全体を完全に終了し、圧縮された出力を一時ファイルに格納する必要があります。 したがって、このツールはfsync()の呼び出しを避けるように設計されていますが、テンポラリファイルディレクトリは十分大きく、これをサポートするのに十分速い必要があるため、一部のメモリを活用することができます。

ベースバックアップでは、最初にファイルのサイズが制限された独立したtarファイルに統合され、ファイルごとの転送オーバーヘッドが比較的大きくなることがありません。 これにより、多くの小さな関係や補助ファイルが含まれている場合に、基本バックアップとリストアをより迅速に行う効果があります。

その他のオプション

暗号化

バックアップを暗号化して圧縮するには、まずgpg --gen-keyを使用して鍵ペアを生成しgpg --gen-key バックアップするマシン上に秘密鍵は必要ありませんが、リストアするには秘密鍵が必要です。 秘密鍵にはパスワードが含まれている可能性がありますが、復元するにはパスワードがGPGエージェントに存在する必要があります。 WAL-Eは、ttyデバイス経由でGPGパスワードを入力することをサポートしていません。

これが完了したら、 WALE_GPG_KEY_ID環境変数または--gpg-key-idコマンドラインオプションを、バックアップおよびリストアコマンドの秘密鍵のIDに設定します。

次に、GPGキーチェーンのロックを解除するための正しいキーで任意のファイルを強制的に復号化することにより、パスワードを持つ秘密鍵で復元する方法の例を示します。

# This assumes you have "keychain" gpg-agent installed.
eval $( keychain --eval --agents gpg )

# If you want default gpg-agent, use this instead
# eval $( gpg-agent --daemon )

# Force storing the private key password in the agent.  Here you
# will need to enter the key password.
export TEMPFILE=`tempfile`
gpg --recipient "$WALE_GPG_KEY_ID" --encrypt "$TEMPFILE"
gpg --decrypt "$TEMPFILE".gpg || exit 1

rm "$TEMPFILE" "$TEMPFILE".gpg
unset TEMPFILE

# Now use wal-e to fetch the backup.
wal-e backup-fetch [...]

# If you have WAL segments encrypted, don't forget to add
# restore_command to recovery.conf, e.g.
#
# restore_command = 'wal-e wal-fetch "%f" "%p"'

# Start the restoration postgres server in a context where you have
# gpg-agent's environment variables initialized, such as the current
# shell.
pg_ctl -D [...] start

ベースバックアップのI / Oの制御

ベースバックアップの読み込み負荷を軽減するには、最初にツールpvを使用します。 このレート制限読み取りモードを使用するには、 wal-e backup-push --cluster-read-rate-limitオプションを使用します。

ロギング

WAL-Eは、以下の環境変数を持つロギング設定をサポートしています。

  • WALE_LOG_DESTINATIONコンマで区切られた値、 syslogおよびstderrがサポートされています。 デフォルトはsyslog,stderrと等価です。
  • LOCAL0からLOCAL7およびUSERへのWALE_SYSLOG_FACILITY

ログ・ステートメントを警告およびエラーに制限するには、– --terseオプションを使用します。

ウォールプッシュのスループット向上

特定の状況では、 wal-pushプロセスは、Postgresによって生成されるWALセグメントに追いつかず、無制限のディスク使用やデータベースの最終的なクラッシュにつながる可能性があります。

--pool-sizeパラメータをwal-push渡すことによって、WAL-EにWALセグメントを一緒にプールしてグループに送信するよう指示できます。 これにより、スループットが大幅に向上します。

バージョン0.7.xでは、– --pool-sizeデフォルトは8です。

AWS IAMインスタンスプロファイルの使用

AWS EC2インスタンスに資格情報を格納することには、ユーザビリティとセキュリティの問題があります。 AWS S3とAWS EC2でWAL-Eを使用する場合、WAL-Eのほとんどの用途は、インスタンスに代わって資格情報を自動的に生成してローテーションするAWSインスタンスプロファイル機能を使用することで利益を得ます。

WAL-Eにこれらの資格情報を使用してS3へのアクセスを指示するには、– --aws-instance-profileフラグを渡し--aws-instance-profile

1つのインスタンス上で実行される複数のプログラムに対して作成された複数のAWS IAMポリシーまたは既存のキー管理インフラストラクチャがある場合、より複雑なシナリオでは、インスタンスプロファイルが好まれない場合があります。

S3エンドポイントの手動指定

別のS3エンドポイント(例えばCeph RADOS)に対してWAL-Eを対象にしたい場合は、 WALE_S3_ENDPOINT環境変数を設定できます。 これは、AWSでエンドポイントや呼び出し規約をきめ細かく制御するためにも使用できます。

形式は次のとおりです。

protocol+convention://hostname:port

有効なプロトコルはhttphttpsで、表記規則はpathvirtualhost 、およびsubdomainです。

例:

# Turns off encryption and specifies us-west-1 endpoint.
WALE_S3_ENDPOINT=http+path://s3-us-west-1.amazonaws.com:80

# For radosgw.
WALE_S3_ENDPOINT=http+path://hostname

# As seen when using Deis, which uses radosgw.
WALE_S3_ENDPOINT=http+path://deis-store-gateway:8888

開発

開発は、開発環境内に存在するツールの毒性に大きく依存しています。 WAL-Eのすべての追加の依存関係はtoxによって管理されます さらに、コード化規則は、WAL-Eに含まれる毒素構成によってチェックされます。

テストを実行するには、次のコマンドを実行します。

$ tox -e py35

実際のBLOBストアアカウントと通信するもう少し時間のかかる統合テストを実行するには、 以下のようにtoxを実行するかもしれません:

$ WALE_S3_INTEGRATION_TESTS=TRUE      \
  AWS_ACCESS_KEY_ID=[AKIA...]         \
  AWS_SECRET_ACCESS_KEY=[...]         \
  WALE_WABS_INTEGRATION_TESTS=TRUE    \
  WABS_ACCOUNT_NAME=[...]             \
  WABS_ACCESS_KEY=[...]               \
  WALE_GS_INTEGRATION_TESTS=TRUE      \
  GOOGLE_APPLICATION_CREDENTIALS=[~/my-credentials.json] \
  tox -e py35 -- -n 8

上記を慎重に見れば、 -n 8tox呼び出しを追加したことに気づくでしょう この-n 8は、 a〜の後ろにあり、それはtoxに、後続の引数が基礎となるテストプログラムpytestに対するものであることを示します。

これは、並列テストの実行を可能にするためであり、これにより、統合テストが完了するまでの時間がわずかに短縮されます。 パラレル実行を犠牲にしない新しいテストの設計要件です。

カバレッジテストは、 pytest-covを使用してこれらのいずれかを組み合わせることによって使用できます。例: tox -- --cov wal_eおよびtox -- --cov wal_e --cov-report html; see htmlcov/index.html tox -- --cov wal_e --cov-report html; see htmlcov/index.html







-wal-e
-, , , , , , , , , , , , ,

執筆者: