LinuxでFiles.comをマウント — 企業向けファイル転送をドライブ化
NetDriveの実験的Linuxビルドで、UbuntuにFiles.comをマウント。ビジネス向けファイル交換アカウントを、ブラウザタブではなく通常のマウントポイントに変える。
Ubuntuのビルドサーバーを運用するあるDevOpsチームは、社外のパッケージングベンダーが毎スプリント受け取りに来るリリースアーカイブの受け渡し場所として、Files.comを使っている。以前は、ビルド成果物をそこに置くには、Files.comのAPI経由でアップロードをスクリプト化するか、踏み台マシンでブラウザタブを見張っている必要があった。NetDriveのLinuxビルドは、同じFiles.comアカウントを通常のマウントポイントとしてマウントするので、ビルドステップはディスク上の他のものと同じようにディレクトリへ書き込むだけで済む。
UbuntuでFiles.comにマウントポイントを与える
NetDrive を使えば Google Drive、OneDrive、S3、SFTP、WebDAV などが Windows と macOS でネイティブドライブとして表示されます — 同期も、まるごとダウンロードも不要です。
- ビルド成果物をマウントされたFiles.comディレクトリに直接書き込む
- 日常的なアップロードとダウンロードに独自のAPIスクリプトは不要
- ひとつのドライブマネージャーで、他のマウント済みクラウドと並行して動作
無料トライアル。永久ライセンスとサブスクリプションプランあり。
Files.comがマウントポイントになると何が変わるか
Files.comはビジネス向けファイルプラットフォームとして作られている——企業が社外のベンダー、クライアント、監査担当者と文書やアーカイブをやり取りするために設定するタイプのアカウントで、フォルダ構造と権限は中央集権的に管理される。マウントがなければ、Ubuntuからこれを扱う方法は、Webコンソールを使うか、無人で実行しなければならない処理(たとえばベンダーが取得できる場所に毎晩ビルドを配置するCIジョブなど)についてはAPIへの手組みの呼び出しを書くかのどちらかになる。
NetDriveはFiles.comアカウントを通常のマウントポイントとしてマウントするので、ディレクトリに書き込めるプロセス——シェルスクリプト、CIステップ、スケジュールされたcronジョブなど——であれば、Files.comのAPIについて何も知らなくてもファイルをそこにプッシュできる。読み取りも同様に逆方向で機能する。ベンダーがアップロードした参照ファイルを取得するスクリプトは、通常のファイルパスを扱うだけでよい。
マウント前に: Linuxでの要件
NetDriveのLinuxビルドは比較ページ上でexperimental(実験的)と表示されている——これはマーケティング上の予防線ではなく、正確なサポート区分である。WindowsとmacOSはNetDriveの主要なテスト対象であり、Linuxも同じプロバイダー接続を利用できるが、ディストリビューションやカーネルバージョンをまたいだ検証の網羅性は同じではない。サポート対象の最低バージョンはUbuntu 16.04で、パッケージはaptやLinuxのパッケージマネージャーではなくgithub.com/NetDrive/installerから配布されているため、更新の確認は手動作業になる。
Files.comのサポートは、NetDriveの現行リリースサイクルで、Koofr、Filen、ImageKit、OpenDriveという4つの新しいプロバイダーと共に追加された。それぞれ異なる種類のストレージニーズを想定したものだ。それによってLinuxビルドがこの接続を扱う方法が変わるわけではなく、認証とマウントは他のすべてのプロバイダーと同じドライブ一覧フローを通る。
UbuntuでFiles.comドライブを追加する
- GitHubのリリースページからNetDriveをインストールする。必要なドライバーコンポーネントについては、そのリポジトリの手順に従うこと——このステップはマシンごとに一度だけ行う。
- NetDriveを起動し、Drive Managerを開く。
- + Add Driveをクリックし、プロバイダー一覧からFiles.comを選択する。
- 求められたらFiles.comアカウントの認証情報でサインインする。
- マウントポイントを設定して確定する。数秒以内に、そのパスでFiles.comのルートフォルダが利用可能になる。
配布がパッケージマネージャーではなくGitHubのリリースを通じて行われるため、スクリプトやcronジョブをそれに依存させて組む前に、マウントが実際に接続されたことを確認しておく価値がある——GUIだけを信用せず、ターミナルからmountをマウントポイントでgrepするか、素のlsで確認すること。
Files.comとの日常的なやり取り
マウントされると、Files.comディレクトリはファイルシステム上の他のパスと同じように振る舞う。リリースアーカイブをそこにコピーすると、バックグラウンドでのアップロードがキューに入り、NetDriveのアップロードトレイに表示されるため、大きな成果物が書き込み中のスクリプトをブロックすることはない。リネーム、削除、フォルダの移動はローカルディスク上と同じようにマウントポイント経由で行われ、NetDriveがその変更をFiles.comへ反映する。
社外との受け渡しにFiles.comを標準採用しつつ、ビルドのフィクスチャはS3バケットやセルフホストのSFTPサーバーに保管しているようなチームにとって、真の利点はその一貫性にある。行き先ごとに異なるスクリプトやクライアントライブラリを用意するのではなく、ひとつのドライブマネージャー、ひとつのマウントという考え方で済む。複数人が同じフォルダを触るような文書のやり取りには、NetDriveのファイルロックも使える。これはOffice文書に限らずどんなファイル種別にも適用されるので、編集中にチームメイトが上書きしてしまうことを防げる。
まとめ
UbuntuでFiles.comをマウントすることで、ブラウザ頼み、あるいはAPIスクリプト頼みのワークフローが、どんなプロセスからも読み書きできる普通のマウントポイントに変わる。ただし、Linuxサポートは実験的であるという条件付きなので、無人実行の何かに依存させる前に、自分のディストリビューションとワークロードで検証してほしい。より広くテストされたプラットフォームでの同じプロバイダーについては、Mount Files.com on Windows with NetDriveやMount Files.com on macOS with NetDriveを参照。Linuxビルド自体についての詳細は、NetDrive on Ubuntu Linuxを読んでほしい。
— Kai, NetDrive