私の講演では、社内でのPythonの進化を思い起こしました。debパッケージにパッケージ化されてベアメタルに展開された最初のサービスから、独自のビルドシステムとクラウドを備えた複雑なモノリポジトリまでです。また、ストーリーには、Django、Flask、Tornado、Docker、PyCharm、IPv6など、長年に渡って遭遇したものが含まれます。
-私のことをお話ししましょう。私は2008年にYandexに来ました。最初はコンテンツサービス、特にYandex.Afishaを担当しました。私はPythonで書いたので、Perlやその他の楽しいテクノロジーからサービスを書き直しました。
その後、内部サービスに切り替えました。内部サービス部門は、徐々に組織の検索インターフェイスとサービスの管理に変わりました。私が成長した単純な開発者から、私たちの部門のPython開発の責任者である約30人まで、多くの時間が経過しました。
重要なポイント：会社は非常に大規模であり、すべてのYandexについて話すことはできません。もちろん、私は他の部門の同僚と連絡を取り、彼らがどのように生きているかを知っています。しかし、基本的に私は私たちの部門、製品についてのみ話すことができます。私の話はこれに焦点を当てます。 Yandexの他のどこかでこれを行っていると時々言います。しかし、それは頻繁には起こりません。
Pythonは社内の多くの場所で使用されています：あらゆるテクノロジー、あらゆるテクノロジースタック、あらゆる言語。頭に浮かぶことはすべて、実験または他の何かとして、会社のどこかにあります。そして、どのYandexサービスでも、必ず1つのコンポーネントまたは別のコンポーネントにPythonが存在します。
私がお伝えすることはすべて、私の出来事の解釈です。私は100％客観的であるふりをしません。これもすべて私の手を通った、それは感情的な色でした。私の経験はすべて個人的なものです。
レポートはどのように構成されますか？あなたが情報をより簡単に認識できるように、そして私が言うことができるように、2007年から現在までの進化全体をいくつかの時代に分解することにしました。レポートはこれらの時代によって厳密に構成されます。時代とは、インフラストラクチャまたは開発へのアプローチにおける根本的な変化を意味します。鉄のインフラストラクチャが変化し、同時にサービスの開発方法、使用するツールも変化しているのであれば、これは時代です。少し調整が必要だったのは明らかです。すべてが同期的に発生したのではなく、これらの変更の間にギャップがあったことは明らかですが、私はすべてを1つのタイムラインに収めて、よりコンパクトにすることを試みました。
私たちにはどんな時代がありましたか？ここでも、すべてが著作権であり、すべての名前は私のものです。最初の時代は「ハードウェア」と呼ばれ、私が入社したときからこれが始まりました。したがって、すべてが少し変わっています。時代は「iron + venv」になりました。さらに、これらの名前の背後に隠されているものを明らかにします。最初に、私があなたに言うことについてのガイドをあなたに与えたいと思います。
次の時代は「コンテナ」であり、ここではすべてがある程度明確になっています。今、私たちが動いている時代は「バイナリアセンブリ」ですが、それについてもお話しします。
各時代はどのように構成されますか？リズミカルなナレーションを作りたかったので、これも重要です。各セクションが厳密に構成され、理解しやすくなりました。時代は、インフラストラクチャ、使用するフレームワーク、依存関係の処理方法、開発環境の種類、およびこのアプローチまたはそのアプローチの長所と短所によって説明されます。
（技術的な一時停止。）はじめに、レポートの構成方法を説明しました。次に、ストーリー自体に移りましょう。
年齢1：鉄
入社して最初に行ったサービスは「誰もが行くところ」。これは最初の大きなDjangoサービスであるAfishaの衛星でした。
グリーシャ・バクノフボブック彼がかつてDjangoをYandexに転送することを決めた理由を知ることができます-一般的に、それは起こりました。 Djangoでサービスを開始しました。
私が来て、彼らは私に言った：みんなが行くところに行こう。その後、すでに何らかのベースがありました。私は接続し、私たちはそれを一種の実験だと考えました-うまくいくかどうか。実験は成功した。 YandexでPythonおよびDjangoを使用してWebサービスを作成することが可能であることに誰もが同意しました。いいね！私たちのインフラストラクチャはこの準備ができており、人々は準備ができており、世界も準備ができています。では、PythonとDjangoを会社全体にさらに配布しましょう。私たちはそれを始めました。 Yandex.Afish、Weatherを書き直しました。その後-テレビ番組。それからすべては霧のように行きました、彼らはすべてを書き直し始めました。
その頃までに、Yandexインフラストラクチャは、バックエンド全体が主にプラスで記述されているように見えました。明らかに、Pythonへの移行により、多くの場所で開発が大幅にスピードアップしました。これは、会社と経営陣から好評でした。それでは、インフラストラクチャについてお話ししましょう。これらのサービスが機能する場所、サービスの内容などです。
これらは鉄の機械だったので、この時代の名前です。アイアンカーとは？これらはデータセンター内の単なるサーバーです。多くのサーバーがあり、それらはすべて、たとえば15台のマシンのクラスターに結合されています。その後、それは30、50、100でした。そして、これらすべてがDebianまたはUbuntuで行われました。その時までに、私たちはDebianからUbuntuに移行していました。すべてのアプリケーションは、標準のinitプロセスを介して起動されました。当時と同じように、すべてが標準でした。アプリケーションがWebサーバー上で通信するために、FastCGIプロトコルとflupライブラリを使用しました。 Pythonを長い間使用している場合は、おそらく聞いたことがあるでしょう。しかし、今では使用しないと思います。これは、道徳的に古く、非常に奇妙なことだったため、非常にゆっくりと動作しました。
その時点で、明らかに、3番目のPythonはありませんでした。Python2.3で書きました。その後、2.4に移行しました。ワイルドな時代。言語も、コミュニティも、エコシステムもまったく異なって見えたので、覚えていたくありませんでしたが、彼らもまた面白かったし、多くの人が惹きつけられました。個人的には、私はPythonの世界に没頭しました。その特異性と奇妙さにもかかわらず、Pythonが有望なテクノロジーであることはすでに明らかであり、あなたはそこで時間を費やすことができます。
重要な点：それから、nginxをまだ使用せず、Apacheを使用しませんでしたが、Lighttpdと呼ばれるWebサーバーを使用しました。あなたが長い間ウェブサービスを作っているなら、おそらくあなたもそれについて聞いたことがあるでしょう。あるとき、彼はとても人気がありました。
フレームワークのうち、実際に使用したのはDjangoです。 Djangoで大きなサービスを作り始めました。会社のどこかにCherryPyがありました-Web.py。これらのフレームワークについても聞いたことがあるかもしれません。現在、彼らは最初の役割ではなく、より若い大胆なフレームワークに長い間追いやられてきました。それから彼らは彼ら自身のニッチを持っていました、しかし結局彼らは遅かれ早かれ死にました、私達は彼らに何かをすることをやめました。彼らはDjangoですべてを始めました。
この時点で、Pythonは社内で非常に普及し、当社の部門からはみ出しました。PythonとDjangoのWebサービスは、社内のどこでも実行されるようになりました。
依存関係の操作に移りましょう。そして、これは、大企業で働くようになったときにも遭遇する可能性が高いことです。企業にはすでに確立されたインフラストラクチャがあるので、それに適応する必要があります。 Yandexには、debインフラストラクチャ、debパッケージの内部リポジトリがありました。 Yandex開発者は、このdebパッケージをコンパイルする方法を知っていると信じられていました。私たちはこのフローに統合することを余儀なくされ、本格的なdebパッケージの形式でプロジェクトを組み立て、次に、debパッケージとして、これらすべてを私が話しているサーバー上に置き、debパッケージとしてクラスターに配置しました。
その結果、すべての依存関係とライブラリ、同じDjango、debパッケージにパックする必要がありました。このために、独自のインフラストラクチャを作成し、内部リポジトリを作成し、その方法を学びました。これは非常に独創的な活動ではありません。RPMまたはdebパッケージを構築しようとした場合、それについて知っています。 RPMは少し単純ですが、debはより複雑です。しかし、すべて同じ-通りから来て、クリックするだけでそれを始めることはできません。少し掘る必要があります。
それ以来、debパッケージを構築してきました。そして、仕事の必要性のためにこれを行ったすべての人が、内部で何が起こっているのかを理解したわけではないようです。彼らは単にお互いから取り、ブランク、テンプレートをコピーし、深く掘り下げませんでした。しかし、内部で何が起こっているのかを掘り起こした人々は、非常に役に立ち、非常に要求の厳しい同僚になりました。突然何かが起こらなかった場合、誰もがアドバイスを求め、微妙なニュアンスとデバッグの助けを求めました。何が入っているのかを知りたかったので、面白い時間でした。したがって、彼は同僚の間で安い人気を得ました。
依存関係のエコシステムに加えて、一般的なコードでの作業もあります。すでにプロジェクトの数は爆発的に増加しており、共通のコードを操作したり、共通のライブラリを作成したりする必要がありました。この種の内部オープンソースを始めました。承認の一般的な機能を作成し、ログやその他の一般的なもの、内部API、内部ストレージを操作しました。これらすべてをライブラリーの形式で行い、それを内部リポジトリーに入れました。最初は、これらはSVNリポジトリで、次に内部GitHubでした。
そして最終的に、これらすべての依存関係をパックしました。これらのすべてのライブラリもdebであり、単一のリポジトリにロードされています。これにより、このようなパッケージ環境が形成されました。新しいプロジェクトを開始した場合、そこにいくつかのライブラリを配置し、機能のデータベースを取得して、すぐにYandexインフラストラクチャでプロジェクトを起動できます。とても快適でした。
私たちの典型的なサーバーはどのように見えましたか？古典的に。システムの依存関係、Pythonの依存関係とアプリケーションがあります。これにはいくつかのことが続きます。まず第一に、同じサーバー上で、したがって同じクラスター上で実行されるすべてのアプリケーションは、同じ依存関係を持つ必要があります。パッケージシステムをインストールする場合、それは常に1つのバージョンであるため、複数存在することはできないため、同期する必要があります。
プロジェクトが少ない場合でも、なんとかして実行できます。たくさんあると、すべてが非常に複雑になります。彼らは異なるチームによって作られ、彼らが同意することは困難です。各チームは、いくつかのライブラリに早期にアップグレードしたい、またはフレームワークをアップグレードしたいと考えています。そして、他の誰もがこれに従うべきです。時間の経過とともに、これは多くの問題を引き起こします。これは私たちにそのような計画を放棄し、次の時代に移行することを促しました。しかし、私はそれについて少し後で話します。
開発環境について話しましょう。しかし、開発環境に対する理解は非常に広がっています。これは、作業方法、コードの作成方法、デバッグ方法、作業方法、テスト場所、実行方法、テスト実行場所などです。
私が入社したとき、私たちは全員リモートの開発サーバーに取り組んでいました。つまり、WindowsやLinuxにある種のデスクトップがあり、それは問題ではありません。正しいDebianと正しいパッケージリポジトリがあるリモートサーバーに移動します。そして、あなたは働き、vim、Emacsを実行し、コードを書き、デバッグを行います。
これはあまり便利ではありませんが、別の人生を特に知りませんでした。Linuxデスクトップやラップトップを手に入れることができる幸運な人たちは、これをローカルで実行しようとするかもしれません。しかし、特別な指示もありませんでした。そんなちょっとワイルドな時間。当時WindowsとMacで暮らしていて、ローカルで開発したいと思っていた特別な人々が、Linuxの中に仮想マシンを立ち上げました。彼らはこの仮想マシン内にコードを記述して起動しました。より正確には、ホストシステムでコードを記述し、仮想マシン内でコードを実行し、何らかの形でファイルシステムを転送して、すべてが同期されるようにしました。それはすべてかなりうまくいかなかったが、どういうわけか生き残った。
この時代、この開発アプローチの長所と短所は何ですか？実際、確かな短所があります。
- 言ったように、共有クラスターは混雑していた。
- クラスター上のすべてのプロジェクトは、同じ依存関係を持つ必要がありました。
- . , , Django . , . 15-20 . . , , — . X, . , . - , - , . . , , . .
- YandexはDebianインフラストラクチャに依存していました。私たちはそれをサポートし、パッケージを構築し、内部リポジトリを維持しました。そしてもちろん、これもあまり良くなく、あまり便利ではなく、あまり柔軟ではありません。あなたは会社のために行われなかった奇妙なことに依存しています。それでも、LinuxディストリビューションとしてのオープンソースソリューションとしてのDebianは、他のタスクのために作られました。
Djangoについてもう少し説明しましょう。なぜそれを使い始めたのですか？レポートの前に、椅子に座っていると、ちょうど11年前にキエフの会議で「なぜDjangoを使うべきなのか？」それから私はそれが自分で好きだった。私はドキュメントを読んで、彼の最初のプロジェクトを作成した称賛された開発者でした、そして彼にはすべて、今ではこのツールはすべてに普遍的に適していると思います。
しかし、それは長い時間がかかりました。私は今でもDjangoが大好きです。Djangoは今でも私たちの部門や会社でかなり多く使用されています。たとえば、2018年の秋の前でさえ、アリスのバックエンドにはDjangoがありました。今では彼女はもういませんが、すぐに始めるために、同僚が彼女を選びました。いくつかの利点はまだ有効です-大規模なエコシステムなので、まだ多くの専門家がいます。あなたが必要とするすべてのバッテリーがあります。
そして、十分な柔軟性があります。あなたがDjangoを使い始めたばかりのとき、それはあなたを非常に制限し、あなたをつなぎ、それを使った特定の作業の流れを必要とするように思われます。しかし、少し深く掘り下げると、多くのことが無効化、変更、構成できます。そして、これを上手に使用できれば、最も人気のあるPythonフレームワークに関連付けられているすべてのパンを取得できます。あなたはすべての短所をバイパスすることができます。それらの多くもありますが、それらは何らかの方法で停止できます。
年齢2：鉄+ venv
この時代の話は終わりました。2011年が終わり、次の時代、「Iron + venv」に移行しました。あなたはすでにハードウェアについて知っています。今、何が起こったのか、envの名前はどこから来たのかを知る必要があります。歌詞の余談：仮想マシンが登場したため、envは発生しませんでした。なぜ引用符で？OpenVZやLXCのようなあらゆる種類のコンテナーのようなものを試し始めたからです。それから、彼らは今のようにではなく、非常に発達が不十分でした。彼らは本当に私たちと一緒に飛んでいませんでした。私たちはまだ共通のクラスターに住んでいましたが、同じマシンで他のプロジェクトと肩を並べる必要がありました。私たちは解決策を探していました。
たとえば、私たちはinitからupstart systemdに切り替えましたが、少し後に、アプリケーションの起動に柔軟性が生まれました。 FastCGIを放棄し、Webサーバーと通信するためのWSGIインターフェイス、またはHTTPの使用を開始しました。この時点で、私たちはすでに多かれ少なかれ最新のPythonを使用しており、エコシステムはすでに非常によく開発されていました。 Webサーバーとしてnginxに切り替えましたが、一般的にはすべて問題ありませんでした。
また、新しいフレームワークを自分自身に適応させ始めました。たとえば、彼らはトルネードを使い始めました。もちろん、そのときまでにFlaskはすでに登場していました。2012年以降、Flaskはすでに非常にファッショナブルで人気があり、DjangoはPythonで人気のあるフレームワークの台座を落とすと脅しました。そしてもちろん、Celeryを使い始めました。プロジェクトが増えると、プロジェクトの数が増え、負荷が高くなり、より多くのタスクを解決し、より多くのデータを処理するため、大規模なコンピューティングクラスターでオフラインタスクを実行するためのフレームワークが必要になります。もちろん、このためにCeleryを使い始めました。しかし、その詳細については後で説明します。
劇的に変わったのは、依存関係との連携方法です。仮想環境の収集を始めました。その頃、Pythonコミュニティは、Pythonライブラリをシステムに配置するのではなく、仮想環境を作成するために必要なすべてのPython依存関係を配置することができるようになりました。この環境は完全に独立しています。マシン上には可能な限り多くの仮想環境が存在できます。これは分離であり、非常に便利な中毒です。あなたはまだそれを使います。そして、私たちはそれをすべて適応させました。最後に、私たちは何をしましたか？仮想環境を作成し、そこにすべての依存関係を置き、debパッケージにパッケージ化し、サーバーに既にロールしました。
その結果、システム内の一般的な依存関係に依存して、すべてのプロジェクトが互いに干渉しなくなり、使用するフレームワークまたはライブラリのバージョンを安全に選択できました。とても便利です。共有コードも変更されました。 Debianインフラストラクチャを部分的に放棄し、特に、debパッケージでのpython依存関係のインストールを停止したため、すべての共通コードと共通ライブラリをアンロードし、そこから配置できるものが必要でした。
スライドからのリンク
その時までに、すでにいくつかのPyPI実装、つまりpythonパッケージのリポジトリ、特にDjangoで記述された実装が存在していました。そして、そのうちの1つを選びました。それはLocalshopと呼ばれています、ここにリンクがあります。このリポジトリはまだ生きており、そこにはすでに約1000の内部パッケージがあります。つまり、2011年から2012年にかけて、Yandexの規模の企業が、約1,000の異なるライブラリ、Pythonで作成されたユーティリティを生成しました。これらのユーティリティは、他のプロジェクトで再利用されると考えられています。スケールを見積もることができます。
すべてのライブラリはこの内部リポジトリで公開されています。そして、そこからPythonにインストールされるか、Debianに戻す特別な自動インフラストラクチャがあります。それは多かれ少なかれ自動化され、便利です。私たちは、Debianインフラストラクチャの維持に多くのリソースを浪費するのをやめました。それは多かれ少なかれそれ自体で働いた。
そして、これは質の高いステップです。これが私が話していたものの図です。
つまり、Python依存症はようやくすべての人にとって同じではなくなりました。システムのものはまだ残っていますが、多くはありません。たとえば、データベースのドライバー、XMLパーサーにはシステムバイナリが必要でした。一般に、当時はこれらの依存関係を取り除くことはできませんでした。
開発環境も変更されました。 venv以降、仮想環境が利用可能になり、そのすべての場所で機能するようになったため、プロジェクトは一般的にローカルプラットフォームで構築できました。これは人生をずっと簡単にしました。 Debianをいじる必要がなくなり、仮想マシンを作成する必要がなくなりました。あなたはちょうど任意のOSを取り、仮想venvを言って、それから何かをpipインストールすることができます。そしてそれはうまくいった。
このスキームの利点は何ですか？私たちはかなり長い間（おそらく3年弱）住んでいるため、このパラメーターの構成により、クラスターホステルでの生活がより簡単になりました。これは本当に便利です。つまり、全社的なDjangoのグローバルな更新に依存するのをやめました。自分に合ったバージョンをより正確に選択し、脆弱性などを修正した場合に重要な依存関係をより頻繁に更新できます。そしてそれは非常に正しい方法でした、私たちはそれが好きで、私たちに多くのすべてを救いました。
しかし、不利な点もありました。システムの依存関係は依然として一般的でした。時々それは発砲し、時にはそれが邪魔になりました。もう一度、私は私たちの部門の範囲を少し超えて、会社について話します。会社が大きいので、誰もが私たちと一緒にこれらの時代に追いついたわけではありません。当時、同社は引き続きPythonの依存関係を操作するためにdebパッケージを使用していました。これらのフレームワークまたはこれらのフレームワークの使用を開始した理由を詳しく説明します。特にトルネード。
非同期フレームワークが必要でしたが、そのためのタスクがあります。 3番目のPythonとそのasyncioはまだ存在していなかったか、または初期状態でしたが、それらを使用することはまだ非常に信頼できませんでした。したがって、使用する非同期フレームワークを選択しようとしました。いくつかのオプションがありました：GeventとTwisted。たぶんもっと多かったのですが、その中から選びました。 Twistedはすでに会社で使用されています。たとえば、Yandex.TaxiバックエンドはTwistedで作成されました。しかし、私たちはそれらを見て、PEPT-8が準拠していない場合でも、Twistedはpythonicに見えないことにしました。そしてGevent-内部にpythonスタックがある種のハックがあります。トルネードを使ってみましょう。
後悔はしていません。一部のサービスではまだトルネードを使用しています。3番目のPythonでまだ書き直していないサービスです。このフレームワークは、コンパクトで信頼性が高く、信頼できることを長年にわたって証明してきました。
そしてもちろんセロリ。これについてはすでに一部説明しました。遅延タスクの分散実行のためのフレームワークが必要でした。わかった。
Celeryがさまざまなブローカーをサポートしていることは非常に便利でした。私たちは、このbを1つまたは別の正しいブローカーを見つけようとするさまざまなタスクに積極的に使用しました。どこかでMongo、どこかでSQS、どこかでRedisでした。しかし、必要に応じて選択を試み、成功しました。
Celeryには多くの不満がありますが、Celeryの内部での記述方法、デバッグ方法、ロギングの種類はさまざまですが、実際には機能します。セロリは、私たちの部署のほぼすべてのプロジェクトで、そして私が知る限り、プロジェクトの外でも、積極的に使用されています。セロリは必需品です。タスクの遅延実行が必要な場合は、誰もがCeleryを使用します。または、最初はそれをとらず、何か他のものをとろうとしますが、それでもセロリに来ます。
次の時代へ。私たちはすでに、より現代的な現在に近づいています。ここで時代の名前がそれを物語っています。
年齢3：コンテナ
社内には、Docker互換のクラウドがあります。内部では、Dockerランタイムではなく、内部開発です。しかし同時に、Dockerイメージをそこにデプロイすることもできます。開発とテストにdockerエコシステム全体を使用することができたので、それは私たちに大いに役立ちました。あらゆる種類のグッズを使用でき、テスト済みの画像を受け取った直後に、このクラウドにアップロードします。それはそこから始まり、必要に応じて機能しました。
その時までに、私たちはすでにどのOSがコンテナ内にあるのか独立していた。どれでも選択できます。もちろん、普通の悪魔ではなく、例えば監督者を使いました。その後、誰もがuWSGIに切り替えました-uWSGIはWebアプリケーションを実行する方法を知っているだけでなく、Webアプリケーションのインターフェースを提供していることがわかりました。また、プロセスを開始するための優れた一般的なものでもあります。
ただし、少し奇妙な設定がありますが、一般的には便利です。私たちは不要な本質を取り除き、uWSGIを介してすべてを行うようになりました。また、Webサーバーとの通信にも使用します。私たちのクラウドの特徴は、uWSGIプロトコルを使用して、コンポーネントとしてクラウドでグローバルに表現されているバランサーと通信できないことです。しかし、これは恐ろしいことではありません。 uWSGIの内部では、HTTPサーバーはかなりうまく実装されており、迅速かつ確実に機能します。
フレームワークはどうですか？ Falconフレームワークが登場し、Cookieの数が多かったため、同じAlice with DjangoをFalconで書き直しました。Cookieはすぐに獲得する必要がありましたが、それほど複雑ではありませんでした。
ある時点でDjangoは少し冗長になりました。速度を上げて、このような大きな依存関係、つまり大きなライブラリを取り除くために、Falconに書き直すことにしました。
そしてもちろんasyncio。私たちは3番目のPythonと古いサービスで新しいサービスを書き始めました-3番目のPythonに書き直すため。私たちの部門だけで、Pythonで書かれた約30のサービスがあります。これらは、バックエンド、フロントエンド、および独自のインフラストラクチャを備えた30の完全な製品です。データプロセッサは、内部と外部の両方のコンシューマにサービスを提供します。
しかし、ご存じのように、同社には何千ものPythonサービスがあり、それらは異なっています。それらは異なるフレームワーク、異なるPython、古いものと新しいものにあります。現在、同社はあなたが知っているほとんどすべての最新のフレームワークを使用しています。 Django、Flask、Falcon、その他、非同期-トルネード、ツイスト、非同期。すべてが使用され、有益です。
時代の構造に戻りましょう。依存関係の扱いをどのように始めたかです。
ここではすべてが簡単です。これで、仮想環境を使用できなくなりました。 debパッケージは必要ありません。イメージのビルド時に、pipで必要なすべてのものをインストールするだけです。完全に隔離されています。誰も気にしません。そして、とても便利です。システムの依存関係に関係なく、Debian、Ubuntuなどのベースイメージを選択できます。私たちが好き。完全な自由。
しかし実際には、ご存じのとおり、完全な自由には別の側面があります。大企業の場合、さらには統一された開発方法と方法、テスト方法、ドキュメントへのアプローチを促進したい場合-この時点で、この動物園が一方で役立つという事実に直面しています。一方、逆に複雑化します。たとえば、サービスが異なるため、すべてのサービスに一部のライブラリを挿入することは簡単ではありません。 Python、Django、またはその他のフレームワークの異なるバージョンがあります。これは物事を複雑にします。しかし最終的には、一般的なサーバーは次のようになりました。
はい、それはサーバーです。完全に独立したコンテナがあります。それぞれに独自のシステム環境があり、アプリケーションがスピンしています。とても快適。しかし、私が言ったように、欠点があります。
ちょっとdockerに戻りましょう。私たちは開発にdockerを使い始めました、それは私たちに大いに役立ちました。
Dockerはすべてのプラットフォームで使用できます。テストを行い、docker-composeを使用し、docker swarmを実行し、小規模なクラスターで本番環境をエミュレートして何かをテストできます。多分負荷テスト。これを積極的に使い始めました。
Dockerは、あらゆる種類の開発環境とも非常によく統合されています。たとえば、私はPyCharmで開発しており、ほとんどの同僚もそうです。組み込みのDockerサポートがあり、その長所と短所がありますが、一般的にはすべてが機能します。
それは非常に便利になり、定性的なステップを実行しました。そして、私たちが今いるのはこの段階です。アプリケーションをデプロイするターゲットクラウドは本格的なDockerランタイムではなく、いくつかの制限がありますが、Dockerを使用して開発すると便利です。ただし、これによってDocker Engineをローカルで使用したり、関連するタスクで使用したりできるようになります。
この時代を振り返ろう。長所-完全な分離、開発に便利なツールチェーン、そして先ほど言ったようにIDEサポート。
欠点もあります。 Dockerはどこにでもありますが、それがLinuxでなければ、少し奇妙に動作します。 Mac用のMacBookインストールDockerを持っているYandex開発者。また、IPv6の動作がおかしい、または何らかの方法で調整する必要があるなどの機能があります。そして、私たちの会社ではIPv6が非常に一般的です。私たちは長い間IPv4アドレスを欠いていたため、内部インフラストラクチャ全体は主にIPv6に関連付けられています。そして、IPv6がラップトップまたはラップトップにあるDockerの内部で機能しない場合、あなたは苦しみ、実際には何もできないので、それをバイパスする必要があります。
それにもかかわらず、私たちはドッカーをとても愛しています。効率的で、優れたエコシステムを備えています。人々は通りから私たちのところにやって来ると私たちは言います-あなたはドッキングすることができますか？彼ら-はい、できます。すべて完璧に。人がやってきて、文字通りすぐに役立つようになります。これは、プロジェクトの開始方法とビルド方法、テストの実行方法、構成の確認方法、またはデバッグ出力について詳しく調べる必要がないためです。男はすでにすべてを知っています。これは外界の事実上の標準であり、効率を高め、ユーザーに機能をより早く提供でき、インフラにお金を費やす必要がありません。
年齢4：バイナリビルド
しかし、私たちはすでに私たちが参入している最後の時代に近づいています。そして、私が言ったとき、私は私のレポートの最初に戻ります：あなたはあなたのインフラストラクチャーアプローチで大企業に来ます。 Yandexでも。以前はDebianインフラストラクチャでしたが、現在は異なります。同社にはかなり長い間、単一のモノリシックリポジトリがあり、すべてのコードが徐々に収集されていました。ビルドメカニズム、分散テストメカニズム、一連のツール、およびまだ使用していないが使用を開始するすべてのものが、その周りに作成されています。つまり、Pythonプロジェクトもこのリポジトリにアクセスします。私たちは同じツールで収集しようとします。しかし、単一のリポジトリーのこれらのツールは主にC ++、Java、およびGoを対象としているため、そこに特殊性があります。
特色はこれです。ここで、プロジェクトのアセンブリの結果がDocker Engineであり、すべての依存関係を持つソースコードが単に存在している場合、プロジェクトのアセンブリの結果は単なる2項であるという結論に達します。 python-interpreter、コード、およびpython-rabbitsとその他すべての必要な依存関係が存在するただのバイナールは、静的にリンクされています。
あなたは来ることができ、互換性のあるアーキテクチャを持つ任意のLinuxサービスにこのバイナーを投げることができると信じられており、それは動作します。そしてそれは本当です。
少し不自然に見えます。 Pythonコミュニティのほとんどの人はそれをしていませんし、あなたもそうしていないと思います。これには長所と短所があります。長所：
- . , , , , , . , . , , . .
- , , , . , , . , . , checkout , , . .
- , .
そしてもちろん、マイナスがあります。それは閉鎖されたエコシステムです。部外者はそれがどのように機能するかを理解するために、すべての機能に没頭する必要があります。彼は試みなければならず、それから初めて有効になります。私たちはこの道の始まりに過ぎません。おそらく、1年か2年後にこの会議に参加した場合、どのようにしてこの変革を経験したかを説明できます。しかし、私たちは将来について楽観的であり、いくつかの社内ルールに従っています。多くの社内特典を手に入れることになるので、そうではなく、むしろそれが好きです。
結論
彼らはより哲学的です。レポート自体は哲学ほど技術的ではありません。
- 進化は避けられません。サービスを作成し、それが長期間存続する場合、サービスを進化させ、インフラストラクチャを進化させ、開発方法を進化させます。
- . , , , .
- . , Django, . , . , , , Django - , . , .
- Python-. , , -. , , . , , , , , : , . , .
トピックは非常に大きいです。私たちがどのようにそして何をしているか、私たちの国でPythonがどのように進化してきたかについて非常に流暢に話しました。各時代を取り、スライドの各ポイントを取り、それをより深く分析できます。また、これで40分で十分です。依存関係、内部のオープンソース、インフラストラクチャについて非常に長い間話すことができます。概要写真をあげました。非常に人気のあるトピックがあれば、次回の交流会や会議で取り上げることができます。感謝。