AmazonEKSはじめにSREチームの須恵です。SREとしてはDocker/Kubernetesを利用した環境の整備を主に推進するかたわら、ときおりフロントエンド開発にも自由に挑戦させてもらったりしています。今回は、kube2iamの仕組みと使い方について書いてみようと思います。EKS上のPodごとにIAMロールを使い分けられるようにするためのツールです。EKSにおいて、クラスターを構成するNodeはEC2インスタンスです。AWSリソースにアクセスするようなPodを動かしたいとき、Podが持てるAWSリソースへの権限は、EC2インスタンスにアタッチされたインスタンスプロファイルに紐づくIAMロールに準じます。DevelopersIOここで、「異なる種類のAWSリソースを使用する複数のPodを、同じクラスターにデプロイしたい」という状況について考えます。Podが本来権限を持つべきでないリソースに誤ってアクセスできてしまうリスクが生じます。そのため、「Node単位」でなく「Pod単位」で権限制御できることにニーズがあります。やって実現?kube2iamが何を行うのか、おおざっぱに説明すると下記です。kube2iamなしAWSに対して何かしたいPod→コンテナが動作するNodeのEC2メタデータAPI→インスタンスプロファイルに紐づくロールの一時クレデンシャルをコンテナに返すkube2iamありAWSに対して何かしたいPod→メタデータAPIへのリクエストをkube2iamコンテナにリダイレクト→kube2iamが「何かしたいコンテナ」のアノテーションに記述されたロールを引き受け(Assume)→当該ロールの一時クレデンシャルをコンテナに返すkube2iamに使用させるIAMロールの作成ここから実際にkube2iamを利用するための準備を進めます。下記のポリシーを作成します。]}次に、「使用サービス:EC2」のロールを作成し、このポリシーをアタッチします。ロールを作成したら、信頼関係の編集を行います。この部分には、ワーカーノード(にアタッチされたインスタンスプロファイル)のIAMロールを記載します。ここまでの作業で、ワーカーノードに対して、AssumeRoleができる権限だけを与えました。RBAC用リソース作成ここからはKubernetesリソースを作成していきます。ClusterRoleBindingです。このServiceAccountはkube2iamのPodがKubernetesのAPIサーバーにアクセスする際に利用します。rbac.authorization.k8s.ioDaemonSet作成ここからは、kube2iamのPodを稼働させるための作業です。「EC2メタデータAPIへのリクエストを奪取する」という役割を遂行するためには、どのノードでリクエストが発生してもよい=すべてのワーカーノードでkube2iamが動作している必要があるので、DaemonSetリソースを作成します。このイメージから起動したコンテナを持つPodが各ノードに配置されます。trueとすることで、EC2メタデータAPIへのアクセスがkube2iamにプロキシされ、直接EC2メタデータAPIにアクセスしないようにすることができます。kube2iamを利用してPodでロールを使用するDaemonSetが作成できたら、任意のロールをPodで使用する準備は完了です。Podのアノテーションにiam.amazonaws.com/roleを追加すると、任意のロールをPodで利用できます。aws-cli最後に続編として、今回セットアップしたkube2iamともう一つのツールを組み合わせ、EKS上のアプリケーションへALBを使ってルーティングを行う方法について書こうと思います。SREチームも人が少しずつ増えてきました。オクトではエンジニアを積極採用中です。気軽に採用サイトを見てみてください。TypeScript)フロントエンド新規プロジェクト本格的に始動どうも、フロントエンドチームの藤井です。ANDPAD施工管理開発チームの目玉の一つである、「横断工程表」というサービス開発が始まりました。3月にリリースした、案件ごとに作れる「工程表」というサービスをより使いやすく改良したものになります。ANDPAD本体に入っている「横断工程表」というサービスを作り直すものでもあります。この横断工程表では、案件や担当者、現場などを横断で同じ工程表上で見れることを機能として入れていきます。いわゆるガントチャートのようなサービスですね。Vueという構成でしたが、今回はフロント側はNuxtで一から作り込むことにしました。理由としては、以下のようなものがあります。バックエンド、フロントのそれぞれの責務がはっきり別れていないのでキャッチアップにも時間がかかるモノリシックな構成のため影響範囲がわかりづらく、毎回リリース前の調査やテストに時間がかかる本体サービスの週一リリースに合わせるため、ちょっとしたフロント側改修も待たなければならないetc...新工程表プロジェクトからの反省点また「新工程表」サービス開発からの反省点もあります。以上のことを踏まえて、今回のプロジェクトでは環境設定から気をつけました。Designを採用し、コンポーネントの管理Lintを導入し、さらにhookを使ってcommit時に自動でlintが走るよう設定TypeScriptを導入し、型を意識した設計にしていくREADMEにディレクトリ構成や注意点などを明記しておくetc....様々な人が開発に携わるからこそ、様々なことを明示的に残しておく必要があると感じました。このサービスが日の目を見るのは、7月末ごろでしょうか。これからガンガン開発を行っていきます!最後に一緒に横断工程表を作ってくれる人を募集しています。TypeScript)Tweetもっと読むコメントを書く2019-06-13施工管理チームにおけるVueコンポーネント設計フロントエンドどうも、施工管理チームのフロントエンドを担当している藤井です。今回うちのチームで取り組んでいるVueプロジェクトのコンポーネント設計の移り変わりについてご紹介したいと思います。v1で成り立っています。(jQueryも入ってたりも)そんな中で、実は本体の「(新)工程表」というサービスと「写真出力」という機能の一部は、最近Vue.jsで書かれています。(旧)工程表から(新)工程表への置き換えプロジェクトはだいたい2018年から約1年。写真出力の一部の置き換えは2019年の4月から約2ヶ月がかかっております。私がこのチームに入ったのは2019年の3月中旬でして、その際はまだ工程表というサービスのみがVueで作られていました。(工程表のサンプル画像↑↑)当時、特にコンポーネント粒度等は仕分けされておりませんでした。そのため、中には1000行を超える巨大なファイルが存在したりしていました。いってもそれは一握りであり、適度に切り分けられ、肥大化していないファイルもありました。.....|初見で思ったのは「粒度の仕分けもされていないし、メンテナンスしにくいな。小さいコンポーネントも大きいものも混在している状態でした。Designを意識した設計に変更しました。pages|「よし!綺麗になったぞ!」これで新しく人が携わることになっても、粒度で別れているから理解しやすいだろうと思っていたのです。実際、工程表というサービスだけの時は、問題ありませんでした。めでたし、めでたし!しかし、次にANDPADの別の機能をVueで開発しようとなりました。それが「写真出力」のドラッグ&ドロップ機能です。(開発途中のサンプル↑↑)ここで、悩みが始まります。コンポーネント設計をどうしようかと。Designベースのディレクトリに、写真出力のVueファイルもポコポコと入れていくのがいいかなと思って途中までやっていました。pages|でも、気づいたのです。「これ、もしかして他のサービス機能とかもVueで作るってなった時に、中でカオスになるよね・・・・。」同じ粒度だからと言って、どんどん同じディレクトリに入れていくと、今後大きくなってきた時に、様々な違った機能のパーツが混在していくことになります。「まあ、ひとまず2つのサービスでしか使ってないからいいかぁ」その時はあまり深く考えずにそのまま進めました。すると、次に別のチームが「そっちでうまく行ったから、こちらのプロジェクトでもVueを使いたい!」と出てきます。さぁここで本格的に頭を悩まします。別のチームといっても、同じリポジトリを使っています。管理という面からも、必然とVueファイルは同じディレクトリを使っていくことになります。Designを続けていってもいいのですが、organismsの中に様々なプロジェクトのコンポーネントが混在することになるからです。atomsとmoleculesは共通部品と当初より考えていたのでよかったのですが、流石にorganismsくらいの大きさになると共通部品がほぼありません。混在させても良いのですが、見通しが悪くなります。今後どんどん別サービスがvueを採用していく可能性も否めませんので、そうなると整理するためにorganismsの下にまたプロジェクトディレクトリを作ることになります。すると、何が起こるかというと、templatesやpagesのディレクトリでも同じプロジェクトディレクトリを作ることになりました。workload.vue|うううう、これはやだなぁ。Nuxtに切り出すプロジェクトもありますし、その点を考慮し、見やすい設計を模索していました。技術顧問や外部の人にも相談して、行き着いた答えが、「atomsとmoleculesはcomponents配下におくが、organisms以上のコンポーネントは各プロジェクトディレクトリ配下に置く」ということでした。workload.vue|こうすることで、何が良いかというと、粒度の責務の切り分けができるようになりました。atomsとmoleculesは共通パーツとして使うもの。それ以上のoraganismsは各プロジェクトで独自のものというふうに分けることができます。それと同時に、一番のメリットは、今後Nuxtへの移行を見据えた際に、移植しやすい構造にもなっております。その際にatomsやmoleculesに関しては、andpad-uiという社内フレームワークに切り出すが可能です。することで、各プロジェクトで持つatomsやmoleculesのパーツは独自の必要最低限のものとなり、コンポーネント管理がしやすくなります。統一されたデザインパーツを使うことにより、デザインの統一性が計れることがわかりました。atomsなどのパーツに関しては、「先にコンポーネントをUIライブラリで作った方が良いのでは?」という意見もあると思います。以前の経験から先にコンポーネントを準備するということはしないことになりました。いうのも、時間をかけてパーツを作っても、結局使わないものが出てくるからです。以前、たくさんのボタンを時間をかけて設計して準備したのですが、結局使われているのはほんの一部ということがありました。リソースが限られている中では、こちらでも紹介されているように、YAGNIって大事だということを身をもって体験しました。qiita.comNuxt移行の段階で切り出したりすることで、サービス横断で本当に必要なパーツがリストに並ぶということになるのです。Designを応用したコンポーネント設計を取り入れてます。今後もっと良い適した設計が現れるかもしれません。その際には柔軟に対応していこうと思います。最近は、社内でフロントエンドに携わる人も増えてきて、社内ルールもまとまってきており、そのことから開発スピードは格段と上がっているように感じます。今後もVue.jsでの置き換え範囲は拡大していく予定です。14:35施工管理チームにおけるVueコンポーネント設計Tweetもっと読むコメントを書く2019-05-30ANDPADのiOSアプリの設計についてiOSアプリの設計について施工管理アプリANDPADのモバイルアプリ開発をしている山下です。今回はANDPADで採用しているiOSアプリの設計について書こうと思います。ANDPADはサービスリリースしてから4年ほど経過しており、ユーザー数も右肩上がりに伸び続けています。アプリもリリースしてから3年半ほど経過して設計を振り返る機会ができたので記事を書いている次第です。基本的な設計方針としてはMVVMを採用しています。3年半ほど前は、アプリ界隈では比較的新しめの設計だったのですが、今では結構当たり前になっているのかなと思います。構成図はこのような感じです。使っている主なライブラリは、RxSwiftRealmAlamofireなどです。比較的今でもよく使われているライブラリなので選択は正解だったと思います。MVVMの部分は、一般的な使い方と基本同じなので説明を割愛します。ApiManagerは、ローカルやサーバー側からのデータ取得を担っています。ScreenUpdateManagerは、複数画面をまたいだ場合のイベント伝搬の責務を担っています。建築系で特有の機能をライブラリ化ANDPADは、iOSだけで5アプリリリースしています。ちなみにAndroidも4アプリリリースしています。Androidアプリの開発も私がやっているのでまた設計の話を別記事で書こうと思います。Oct,inc開発当初から、建築業界という広いドメインを扱うサービスなので用途毎に複数のアプリをリリースしようと決めていました。複数のアプリをリリースするにあたり、共通化できそうな機能は独自ライブラリとして切り出す手法を初期段階から行なっていました。同じような機能を実装する場合はOSSのライブラリと同じような感じでライブラリをインストールするとアプリから呼び出せるようになっています。ライブラリの管理はCocoaPodsを使っています。カメラ機能など、建築現場特有の機能などはよく要望を頂くのでライブラリ化することでだいぶ助かっています。設計を振り返って今回設計を振り返ろうと思ったきっかけは、あるアプリをリニューアルするにあたり現状の設計を見直して改善できる部分を洗い出そうと思ったからです。今までの設計の中で失敗だったなと思ったのは役割があいまいなManagerクラスを作ってしまったことや、色んな場所から呼び出したいモジュールを安易にシングルトンにしてしまったことなどです。次の設計では、このあたりを解決した構成を考えたいと思っています。形になった段階でまた記事を書こうと思います。弊社では、業務拡大中で最高の設計をしたいiOSアプリ開発者を積極採用しております。みなさまのご応募お待ちしております!!エンジニア採用サイトに募集職種や、会社の雰囲気の分かるインタビュー記事があります。16:11ANDPADのiOSアプリの設計についてTweetもっと読むコメントを書く2019-05-235月の社員総会を行いました!!今週の月曜日は月に1度の総会の日でした!各部門より先月からの取り組みや達成率、データなどが全社員に共有されます。「へぇー、そんなことしてるんだ」とか「そういうところにお客さんは喜ぶのかぁ」など、営業チームやCSチームから話を聞いてて、勉強になる所もたくさんあります。開発部にも発表のセクションがあります!しかもいつもなぜかトップバッター。日頃、対応に追われていて忘れがちになるものですが、やはり頭に入れておかなければならないことです。何のために今のプロダクトを開発しているのか、ただ単にレンガを積むことになっていないか。最終的にはここに繋がっていることを忘れてはなりません。次のスライドの中で、4つのことを「行動」というパートで述べていました。最近オクトでは、開発部それぞれのチームに技術顧問の方に来て頂いております。それぞれの分野で知見を持っていらっしゃる方々のお力を借りることで、より良いサービス開発に繋げています。それだけではなく、個人のミッション設定、チームとしてのロードマップづくり、そしてそこから得られる結果としてのKPIの見える化に取り組むことで、「組織として動くための構造づくり」に繋げています。CTOからのお話の後は、各プロダクトそしてエンジニア部門からの発表タイムです。施工管理チーム、ERPチーム、新規開発チームからそれぞれプロジェクトの進捗が発表されます。その後にそれぞれ、フロントエンド、SRE(改善)、インフラ、デザインと発表の時間が取られました。導入ツールの説明セキュリティ面での取り組みetc...この総会は開発部だけでなく、営業部やCSなど、他部署の人たちも参加しています。普段開発がどんなことに取り組んでいるのかを知ってもらういい機会でもあります。マーケティングそしてCEOとお話が続きました。するようなお話も多々。総会が終わったら普段はそれで解散なのですが、今回は懇親会が催されました。お酒とお料理が振舞われ、部署を超えての交流タイム〜〜東京だけじゃなく、各支社からも集まっているし、新しくジョインしたメンバーも多いので、オフィスのフリースペースはもうパンパン。最後にみんなで集合写真。パシャり!総会は多くの社員が顔を合わせる日でもあり、交流も多く生まれます。プロダクトチームの藤井です。普段はフロントエンド機能開発や改善を担当しています。先日、永田町GRIDで開催されたNuxtMeetUp#8に参加してきました!nuxt-meetup.connpass.comこのイベントは会を追うごとに大きくなっており、今回初めて登壇側で出させてもらうことに。知り合いも多くいましたので、あまり緊張することなく楽しめたかなぁと思います。今回発表させてもらいました内容ですが、こちらになります!speakerdeck.com今回の発表目的は、技術説明というよりかは、知見共有になります。入社してから2ヶ月半ほどは、別のNuxtプロジェクトに携わっておりました。3月ごろから、「本体」と呼ばれるメインのサービスのある機能のフロント部分を担当することになり、その際にNuxtに切り出せないかと「1日検証」した際のお話です。1日で移行なんて無理があると思われた方、全くその通りだと思います。今回の目的は、「移行のための調査」であるので、ざっくりと、どういったところに懸念点等があるのかを探るためでしたので、短時間で良いと判断しました。(詳しくはスライドをご覧下さい)今回ですが、3月の時点でのいきなりの移行は難しいと判断しましたが、諦めた訳ではありません。移行を見据えた開発や修正を引き続き行なっていきます。進捗はこちらのブログで更新していきますので、よろしくお願いします。最後にこちら弊社のエンジニア採用サイトになります。どんな会社なのか雰囲気を感じて頂ければ幸いです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。