どこでもソフトウェア開発：私の分散型リモートワークプレイス

リモートフリーランサーとして働くことには多くの利点がありますが、効果的な分散作業環境を設定することは実際の課題になる可能性があります。 もちろん、実行できるアプローチはたくさんあり、すべての人に適した「最良の」方法は1つではありません。 リモートデジタルワークプレイス組織は確かに非常に個人的なものであり、ある開発者にとってはうまく機能するものが、他の人にとってはまったくうまく機能しない場合があります。

そのことを念頭に置いて、ここで紹介するセットアップは、特に開発とシステム管理の両方を含むリモートプロジェクトで、個人的にうまく機能するものです。 このアプローチには多くの利点があると思いますが、各読者は、運用上のニーズと個人的な好みの組み合わせに基づいて、自分に最適な方法でこれを適応させる方法を検討する必要があります。

私のアプローチは主に、SSHおよびLinux上の関連ツールによって提供される機能に基づいています。 MacOSおよびその他のUnixライクなシステムのユーザーは、システムが説明されているツールをサポートしている限り、説明されている手順を利用できることに注意してください。

私自身のパーソナルミニサーバー

私のセットアップの重要な最初のステップは、私の自宅にあるRaspberry Pi 2搭載サーバーであり、ソースコードリポジトリからデモサイトまですべてをホストするために使用されます。

私は旅行をしますが、私のアパートは、まともなインターネット接続（100 Mbit /秒）を備え、追加の遅延がほとんどない、リモートの「固定された運用ベース」として機能します。 これは、私のアパートからは、基本的に宛先ネットワークの速度によってのみ制約されることを意味します。 ここで説明するセットアップは、必須ではありませんが、このタイプの接続で最適に機能します。 実際、私は比較的低帯域幅のADSL接続を使用しているときにもこのアプローチを使用しており、ほとんどのことが問題なく機能しています。 私の経験では、唯一の実際の要件は、帯域幅が計測されていないか、汚れが安いことです。

住宅ユーザーとして、私はISPが購入できる最も安いホームネットワークルーターを持っていますが、これは私がしなければならないことには十分ではありません。 したがって、ISPがルーターを「ブリッジモード」にするように要求しました。このモードでは、ルーターは接続ターミネーターとしてのみ機能し、接続された1つのシステムにPPPoEエンドポイントを提供します。 これは、デバイスがWiFiアクセスポイントとして、または一般的なホームルーターとしても機能しなくなることを意味します。 これらのタスクはすべて、プロ仕様の小型MikrotikルーターRB951G-2HnDによって処理されます。 ローカルネットワーク（10.10.10.0/24に番号を付けました）のNATサービスを実行し、それに接続されている有線および無線デバイスにDHCPを提供します。 MikrotikとRaspberryPiは、既知のアドレスが必要なコンテキストで使用されるため、静的アドレスを持っています。 私の場合、それらはそれぞれ10.10.10.1と10.10.10.10です。

自宅の接続に静的IPアドレスがありません。 私の目的では、24時間年中無休のサイトではなく、個人またはSOHOの作業環境を作成することが目標であるため、これはリモートで作業する場合の軽度の不便にすぎません。 （サーバーに静的IPアドレスが必要な場合は、静的IPアドレスのコストが下がり続けており、かなり安価な静的VPN IPオプションを利用できます。）私が使用しているDNSブローカー、Joker.comは、他のすべてのサービスと一緒に無料の動的DNSサービスを提供しているため、個人ドメインの1つのサブドメインが動的名として存在します。 私はこの名前を外部から自分のネットワークに接続するために使用し、MikrotikはSSHとHTTPをNAT経由でRaspberryPiに渡すように構成されています。 個人のホームサーバーにログインするには、 ssh mydomain.example.comに相当するものを入力するだけです。

どこでもデータ

Raspberry Piが提供しない重要なことの1つは、冗長性です。 私は32GBのカードを装備しましたが、何かが起こった場合に失うデータはまだたくさんあります。 これを回避し、住宅のインターネットアクセスに問題が発生した場合にデータに確実にアクセスできるようにするために、すべてのデータを外部のクラウドのようなサーバーにミラーリングします。 私はヨーロッパにいるので、2GBのRAMと500GBのSSHDを提供するローエンドのVIACPUを搭載したOnline.netから最小の専用ベアメタル（つまり非仮想化）サーバーを入手するのは理にかなっています。 Raspberry Piミニサーバーと同様に、高いCPUパフォーマンスやメモリさえ必要ないので、これは完全に一致します。 （余談ですが、2つのPentium 3CPUと1GBのRAMを搭載し、おそらくRaspberry Pi 2の半分の速度であった最初の「大きな」サーバーと、それを使って素晴らしいことをした方法を覚えています。最適化への関心。）

rdiff-backupを使用して、RaspberryPiをリモートのクラウドのようなサーバーにバックアップします。 システムの相対的なサイズから判断すると、これらのバックアップは事実上無制限の履歴を取得します。 私がクラウドのようなサーバーに持っているもう1つのことは、ownCloudのインストールです。これにより、プライベートのDropboxのようなサービスを実行できます。 製品としてのownCloudはグループウェアやコラボレーションに移行しているため、より多くの人が使用することでさらに便利になります。 使い始めてから、文字通りRaspberry Piにもクラウドのようなサーバーにもバックアップされていないローカルデータはなく、ほとんどが2回バックアップされています。 データを重視する場合、追加のバックアップ冗長性を作成することは常に良いことです。

SSHFSの「魔法」

最近の私の仕事のほとんどは、直接Webに関連しないものを開発することを含んでいるので（衝撃的です、私は知っています！）、私のワークフローはしばしば古典的な編集-コンパイル-実行サイクルに従います。 プロジェクトの特定の状況に応じて、ファイルをラップトップにローカルに配置するか、ownCloud同期ディレクトリに配置するか、さらに興味深いことに、ファイルをRaspberryPiに直接配置してそこから使用することができます。 。

後者のオプションは、SSHFSのおかげで可能になりました。これにより、RaspberryPiからリモートディレクトリをローカルにマウントできます。 これはほとんど魔法のようなものです。SSHアクセス権を持つ（ユーザーがサーバー上で持っている権限の下で動作する）任意のサーバーにリモートディレクトリをローカルディレクトリとしてマウントできます。

リモートプロジェクトディレクトリがありますか？ ローカルにマウントして、それを実行します。 開発やテストに強力なサーバーが必要で、何らかの理由でそこに行ってコンソールでvimを使用することはできない場合は、そのサーバーをローカルにマウントして、好きなことを実行してください。 これは、インターネットへの低帯域幅接続を使用している場合に特に効果的です。コンソールテキストエディターで作業している場合でも、そのエディターをローカルで実行してから、SSHFS経由でファイルを転送するだけで、エクスペリエンスが大幅に向上します。リモートSSHセッションで作業するよりも。

異なるリモートサーバー上のいくつかの/etcディレクトリを比較する必要がありますか？ 問題ない。 SSHFSを使用してそれぞれをローカルにマウントしてから、diff（またはその他の適用可能なツール）を使用して比較します。

または、大きなログファイルを処理する必要があるが、ログ解析ツールをサーバーにインストールしたくない場合（依存関係が膨大なため）、何らかの理由でログをコピーするのは不便です。 繰り返しますが、問題ありません。 SSHFSを介してリモートログディレクトリをローカルにマウントし、必要なツールを実行するだけです。たとえそれが巨大で、重く、GUI駆動であっても。 SSHはオンザフライ圧縮をサポートし、SSHFSはそれを利用するため、テキストファイルの操作はかなり帯域幅に優しいです。

私の目的では、 sshfsコマンドラインで次のオプションを使用します。

sshfs -o reconnect -o idmap=user -o follow_symlinks -C server.example.com:. server

これらのコマンドラインオプションの機能は次のとおりです。

• -o reconnect -SSHエンドポイントが壊れた場合に再接続するようにsshfsに指示します。 デフォルトでは、接続が切断されると、マウントポイントが突然失敗するか、単にハングするため、これは非常に重要です（これはより一般的であることがわかりました）。 これがデフォルトのオプションであるべきだと私には本当に思えます。
• -o idmap=user user-リモートユーザー（つまり、接続先のユーザー）をローカルユーザーと同じになるようにマップするようにsshfsに指示します。 SSH経由で任意のユーザー名で接続できるため、これにより「修正」され、ローカルシステムはユーザーが同じであると見なします。 リモートシステムのアクセス権とアクセス許可は、通常どおりリモートユーザーに適用されます。
• -o follow_symlinks任意の数のリモートファイルシステムをマウントできますが、1つのリモートディレクトリ、つまりホームディレクトリだけをマウントする方が便利で、その中に（リモートSSHセッションで）重要なディレクトリへのシンボリックリンクを作成できます。 /srv 、 /etc 、 /var/logなどのリモートシステム上の他の場所。 このオプションにより、sshfsはリモートシンボリックリンクをファイルとディレクトリに解決し、リンクされたディレクトリをたどることができます。
• -C -SSH圧縮をオンにします。 これは、ファイルのメタデータとテキストファイルで特に効果的であるため、デフォルトのオプションである必要があるように思われるもう1つのことです。
• server.example.com:. -これはリモートエンドポイントです。 最初の部分（この例ではserver.example.com ）はホスト名であり、2番目の部分（コロンの後）はマウントするリモートディレクトリです。 この場合、「。」を追加しました。 SSHログイン後にユーザーが終了するデフォルトのディレクトリを示します。これは私のホームディレクトリです。
• serverファイルシステムがマウントされるローカルディレクトリ。

特に、低帯域幅または不安定なインターネット接続を使用している場合は、SSH公開/秘密鍵認証を備えたSSHFSとローカルSSHエージェントを使用する必要があります。 このように、SSHFSを使用するときにパスワード（システムパスワードまたはSSHキーパスワードのいずれか）の入力を求められることはなく、再接続機能はアドバタイズされたとおりに機能します。 SSHエージェントが設定されていないため、セッション内で必要に応じてロック解除されたキーが提供される場合、通常、再接続機能は失敗することに注意してください。 WebにはSSHキーのチュートリアルがたくさんあり、私が試したGTKベースのデスクトップ環境のほとんどは、独自のエージェント（または「ウォレット」または彼らがそれを呼び出すことを選択したもの）を自動的に開始します。

いくつかの高度なSSHトリック

世界中のどこからでもリモートアクセスでき、高帯域幅接続であるインターネット上の固定小数点を持つこと-私にとってはそれは私のRaspberry Piシステムであり、実際には任意の汎用VPSである可能性があります-ストレスを軽減し、データの交換とトンネリングに関するあらゆる種類のもの。

簡単なnmapが必要で、携帯電話ネットワーク経由で接続していますか？ そのサーバーから実行するだけです。 一部のデータをすばやくコピーする必要があり、SSHFSはやり過ぎですか？ プレーンSCPを使用するだけです。

サーバーへのSSHアクセスはあるが、そのポート80（またはその他）が接続元の外部ネットワークにファイアウォールで保護されているという別の状況に直面する可能性があります。 これを回避するには、SSHを使用してこのポートをローカルマシンに転送し、 localhostを介してアクセスします。 さらに興味深いアプローチは、SSH経由で接続しているホストを使用して、おそらく同じファイアウォールの背後にある別のマシンのポートを転送することです。 たとえば、次のホストがある場合：

• 192.168.77.15-ファイアウォールの背後にあるリモートローカルネットワーク内のホスト。ポート80に接続する必要があります。
• foo.example.com-SSHアクセス権を持つホストで、上記のホストに接続できます
• ローカルシステム、ローカルホスト

192.168.77.15のポート80をfoo.example.comSSHサーバー経由でlocalhost：8080に転送するコマンドは次のようになります。

ssh -L 8080:192.168.77.15:80 -C foo.example.com

-Lの引数は、ローカルポート、および宛先アドレスとポートを指定します。 -C引数は圧縮を有効にするため、帯域幅を節約でき、最後にSSHホスト名を入力するだけです。 このコマンドは、ホストへのプレーンSSHシェルセッションを開き、それに加えて、接続可能なローカルホストポート8080でリッスンします。

SSHが近年開発した最も印象的なトリックの1つは、実際のVPNトンネルを作成する機能です。 これらは、接続の両側で仮想ネットワークデバイスとして現れ（適切なIPアドレスが設定されていると仮定）、物理的にそこにいるかのように（ファイアウォールをバイパスして）リモートネットワークにアクセスできるようにします。 技術的な理由とセキュリティ上の理由の両方から、これにはトンネルに接続されている両方のマシンでのルートアクセスが必要であるため、ポートフォワーディング、SSHFS、またはSCPを使用するよりもはるかに便利ではありません。 これは、その方法に関するチュートリアルを簡単に見つけることができる上級ユーザー向けです。

どこでもリモートオフィス

単一の場所から作業する必要がないので、私が概説したテクノロジーとテクニックを使用して、インターネット接続が半ばまともな場所ならどこからでも文字通り作業できます（メカニックで車を待っている間を含む）。 SSH、転送ポート、ドリルトンネルを介して外部システムをマウントし、日光浴をしたビーチを見下ろしたり、霧の街で流行に敏感な環境にやさしいコーヒーを飲みながら、プライベートサーバーやクラウドベースのデータにリモートアクセスします。 早くやれよ！