#cisco ansible python linux docker gns3 packettracer

[stevecosner]

Repo with packet tracer file, GNS3 configs, Python config files and Ansible playbook for configuring and playing around with Cisco routers and NetDevOps configurations. http://bit.ly/2ORnTdU

[tak4hir0]

ITの技術や知識はツールの習得と表裏一体ではないか、というアイデアをラフなメモ。 とても当たり前の内容かもしれない。 【1】昨年からもう一度、コンピュータの基本技術を習得すべきと考えて、Ruby、Python、Linux、ネットワーク、機械学習、深層学習、コンパイラなどを勉強し始めた。 実は、正直なところ、AWSを習得したかったけれど、挫折してしまった。 マーケットプレイスから試したいアプリを落として設定すれば、アプリは簡単に動く。 EC2で普通にLinuxコマンドを叩けば、��通にセットアップできる。 VPCで書籍の通りにネットワークを作れば、それなりに動く。 でも何か分かったような気がしなかった。 何か真似事しているだけのような気がした。 なぜだろうか？ いろいろ考えた結果、やっぱり基本技術が分かってないなあ、という思いがあった。 【2】ITの技術や知識の習得は、財務や法律、経済学などの分野の知識の習得とは異なる気がする。 具体的には、ITの技術や知識を知っているだけでは意味がなくて、その技術や知識を実装しているツールを使いこなせて、そこから新しいものを生み出すことができて初めて意味を持つのだ、と思う。 理由は、2つある。 【3】1つ目は、ITの技術や知識を知っているだけで、プログラミングの開発環境、Linuxコマンドを動かせるサーバー環境、UMLやデータモデルを描いて実際に画面まで動かす、などの実際に動かせる環境でツールを使いこなせなければ、実際の仕事に使えないからだ。 たとえば、RubyやPythonの文法を知っていると言っても、実際に動くアプリを生み出すには、プログラミングの開発環境を揃えて、デバッグしたり、コンパイルしたり、デプロイする環境が必要に��る。 昔なら、VisualStudioでVBやC++を書いていた時も、VisualStudioに数多くのパッチを当てたり、SQLServerなどのバージョン依存に泣かされていたのを思い出す。 今でも、単にRubyやPythonの文法を習ったとしても、実際に開発環境を揃えるのは割と大変だ。 実際、Railsは優れたWebフレームワークだが、VerUpが激しいし、大量のGemが必要になるので、慣れていなければ、バージョン依存ですぐに動かなくなる。 PythonもNumpy、Pandas、MatplotLibのVerUpは激しいので、すぐに古いバージョンのAPIは使えなくなっている。 ただし、Pythonの場合、Anacondaがあるおかげで、以前よりもバージョン依存地獄にはまらなくなったように思う。 たとえば、WordPressやTracなどのWebシステムを通じて、Webアプリの機能や特徴を理解したとしても、Linux上にソースをデプロイして、負荷分散に耐えられるようなネットワーク設計を行ったり、不正なアクセスを制御するようにアクセス制限を課す、とか、いろんな設定作業が必要になる。 特に、インフラ周りの開発環境は、一昔前まで構成管理できない環境だったから、設定ファイルを一度修正すると、元の環境に戻せないリスクが多かった。 それゆえに、数多くの「○○_backup_yyyyMMdd.ファイル」みたいなファイルがたくさんできてしまって、ゴミファイルなのに消せなくなる、とかいろいろな苦労もあった。 ただし、今なら、DockerなりAnsibleで、環境構築の構成管理が可能になったので、いつでも環境を複製したり、再現することが楽になったのはありがたい。 たとえば、UMLでオブジェクト指向設計を習得しても、データモデリングの手法を通じて業務システム設計が分かったとしても、実際にUMLやDOAのモデルを描けるツールが必要だ。 実際にモデルを描いてみると、数多くのモデル管の整合性を取るのが大変なのが分かるし、実はモデリングの記法に制限がありすぎて、あるべき機能を描きにくい、という気づきもあったりする。 特に、データモデリングの手法は日本では昔から技術が蓄積されていて、そのノウハウも十分にあるし、業務システム設計にとても役立つのに、さほどそのノウハウが普及していないのは、データモデリングのツール自体がオープンソースで提供されていなかったり、使われていないからだ。 ER図を描くだけでも気づきは多いのに、ER図を描けるモデリングツールはそもそも標準がないのが実情。 だから、データモデリングの考え方自体も普及していない。 【4】2つ目は、ITの技術や知識を使ったベストプラクティスは、ツールの一機能として実現されているので、ツールの機能を使いこなすことで、自然に知識やノウハウを身につけられるからだ。 たとえば、Rubyの開発環境で最も優れているのはRubymineだろう。 RubymineでRubyを書いてみると、デバッグもできるし、ブレイクポイントを置いて、実際に動く変数の中身もウォッチできる。 しかも、RubymineにはRubyという動的言語であっても、リファクタリング機能が付属しているので、ちょっとした変数名の置換、ロジックをメソッドで抽出する、などの操作を簡単に行える。 つまり、リファクタリング本で知られているリファクタリングのベストプラクティスがRubymineのツールの1機能として実現されているので、Rubymineを使いこなしていくうちに、リファクタリング技術にも慣れて、きれいなコードを書くノウハウも身に付く。 もちろん、テストユニットのソース支援機能もあるから、自動テストも実装できるから、そういう機能を使っていくうちに、プログラミングの能力も身についていく。 たとえば、CCNAのようなCisco機器の知識、ネットワークの一般的な知識を身に着けたい場合は、Ciscoのルータやスイッチを実際に中古品で購入して、オンプレのネットワーク設計を行いたい。 しかし、実際はそこまでお金を払わなくても、PacketTracerのようなシミュレータ、GNS3のようなエミュレータが無料であるので、それらを使ってPC上でネットワークのトポロジーを作って動かしてみればいい。 実際に試してみると、L2スイッチでVLANやSTPの設定、ルータでRIP、OSPF、デフォルトゲートウェイ、サブネッティングによるIPアドレス付与、などの基本的なネットワーク設計は非常に難儀な作業であることがよく分かる。 IPアドレスの数字がちょっと間違えただけでも、すぐに疎通できなくなる。 100人以上の社員がいる社内ネットワーク構築で、ルータを10個以上配置する場合、ネットワークの冗長化や負荷分散、セキュリティ面をきちんと考えておかないと、すぐにユーザからクレームが来るだろう。 そういう設計を行うための技術は、たとえば、STPやHSRPのような冗長化や負荷分散、ACLやPortSecurity、AAAのようなセキュリティの機能があるので、それらをCisicoコマンドで実際に実現すればいい。 そういうネットワーク設計をルータやスイッチのような実機ではなく、PacketTracerやGNS3のような無料ツールで事前にネットワーク・トポロジーを試しておけば、いろんなノウハウが身に付くだろう たぶん、クラウドも同じように、実際にAWSで色々試しながら、身につけた方が習得が速いはず。 たとえば、Redmineは単なるITSやBTSではなく、プロジェクト管理ツールとして使われるようになった。 すると、プログラマ出身だが、プロジェクトリーダーの役割は初めての経験で、そんなにチームビルディングに自身がない人であっても、Redmineというツールの機能を駆使すれば、基本的なスケジュール管理や課題管理はこなせるようになる。 また、アジャイル開発のプラクティスとRemdineの各機能は相性がいいので、チームビルディングやコミュニケーション活性化に活用することもできるだろう。 つまり、Redmineの機能を十分に把握できれば、自然にプロジェクト管理力も身についていく。 Redmineのいろんな機能は、10年以上のOSS開発を通じて、世界中の開発者の要望が実現されていて、それらは全て、ソフトウェア開発に役立つように作られたからだ。 逆に言えば、PMBOKのような���識を持っていたとしても、実際のプロジェクトの現場で発揮できなければ意味がない。 Excelで自前でガントチャートによるスケジュール管理を作ったり、自前で工数管理のVBAやEVMのVBAを作り込んだりしていたプロジェクトリーダーを実際に見てきた。 たしかに彼らはそういうツールを作り出すだけのVBA能力があり、マネジメント能力も会ったわけだが、僕はOSSのプロジェクト管理ツールとかGitHub、GitLabなどを使いこなすことで自然にベストプラクティスが身についていく、という成長のやり方の方が好きだ。 「ツールがプロセスを改善していく」という発想が僕は好き。 ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索 チケット駆動開発はツールによる改善か、プロセスによる改善なのか: プログラマの思索 ツールがサポートすれば考え方も変わる: プログラマの思索 チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 開発プロセスの型をツールで構築する #tidd: プログラマの思索 【4】そんな事を思うと、ITの技術や知識はツールの習得と表裏一体である、という事実を改めて感じている。 換言すれば、プログラミング開発環境、サーバー環境、ネットワーク環境、プロジェクト管理ツール、ソースコード管理ツールなどのツールを使いこなしていけば、そのツールの機能に実装されているベストプラクティスは自然に身に付くのだ。 それらのツールの機能には、長年の蓄積で得られたコンピュータ科学やソフトウェア工学の理論、数多くのプログラマやネットワーク技術者が苦労して導いてきた泥臭いノウハウが数多く詰まっている。 だから、教科書を通じてIT技術の知識を習得するよりも、実際に開発環境を揃えてプログラムを書いたり、サーバーを動かしたり、プロジェクト管理ツールを準備して実際にスケジュール管理や課題管理をやってみる、という体験の方が重要だと思う。 そして、そういう試行錯誤は、20代のような若いうちにやった方がいい。 最近気づいたが、年齢を取るほど、PCの前に長時間座ってコマンドを叩くのが割ときつくなってくる。 いくらツールを通じて知識を習得すればいい、と言っても、ツール自体もどんどん進化するから、それらにキャッチアップしていくのも大変。 視力が落ちてくるし、老眼になってくるし、体力面も厳しくなる。 昨今のDXというバズワードの流行を見ると、ビジネスも生活もあらゆる場面で、全てがソフトウェアで代行されていくだろう。 そういうソフトウェアを自分のものとして制御していくためにも、ソフトウェアの基本的な知識や技術は習得しておきたい。だからこそ、ツールの機能を習得することで、自然に知識やベストプラクティスが得られるように、そのやり方にも慣れておきたい。