フロント側エラー対応にBugsnag活用

はじめに

フロントエンドチームの藤井です。

今回は、Bugsnagの導入について紹介します。

 

Bugsnagとは

アプリケーションのエラー監視ツールですね。

 

www.bugsnag.com

 

以前よりANDPAD本体には導入してされておりましたが、フロント側の一部分をVueに置き換える過程で抜けておりましたので、そちらにも導入することになりました。

 

f:id:yohei-fujii:20190720022125g:plain

(↑写真出力ドラッグ&ドロップページ)

 

f:id:yohei-fujii:20190720021952g:plain

(↑新工程表の画面)

 

導入してみる

こちらのページを参考にしながらすると、サクッと終わります。

docs.bugsnag.com

 

本番環境でのみ通知を飛ばしたいので、bugsnag.jsでこのように書いて読み込ませました。

import Vue from 'vue'
import bugsnag from '@bugsnag/js'
import bugsnagVue from '@bugsnag/plugin-vue'

if (process.env.NODE_ENV === 'production') {
const bugsnagClient = bugsnag('hogehogehoge') // APIKEY
bugsnagClient.use(bugsnagVue, Vue)
}

 *hogehogehogeは登録時に割り振られたAPI keyをご利用下さい

 

実際に導入が完了すると、コンソールにこのように表示されます

f:id:yohei-fujii:20190718110035p:plain

 

運用してみる

現在、基本的にフロント側では、1. Weekly Summaryを参考に、そして2. Dashboardを詳しく見るという流れで確認しています。

 

1. Weekly Summary

こちらは週次でサマリーがメールで届きます。新規発生件数や、どのページで起きているのかなど概要を確認することができます。

 

 

f:id:yohei-fujii:20190718101301p:plain

 2. DashBoardから

その次に、BugsnagのDashboradへ行き、そこに出ている一覧を眺めます。本来は、全て対応したいのですが、時間も限られていますので、最低限自分の担当している箇所を探して対応するようにしています。

 

f:id:yohei-fujii:20190718101949p:plain

 

上記のように今週も「新工程表」と「写真出力」のバグを発見しました。

 

対象の項目をクリックすると以下のことがわかります。

- どのような操作をした時に起きたのか

- どのデバイスで起きたのか

- どのファイルのどの行が起因になっているか

 

あとは、対象のバグ起因になっている箇所に行き、修正してPRして完了です。

 

まとめ

実装時に気をつけてはいるものの、漏れやブラウザによる差異の吸収ができていないために、何かしらのエラーが出ることが多いです。

 

完璧なエラーの出ないプロダクトは理想ではありますが、なかなか難しい現実でもあります。ですので、Bugsnagなどを用いることで、いち早くエラーに気づき、対応を行うという体制にしています。

 

本当に便利なツールですので、活用してみることをオススメします。

最後に

一緒にANDPADを作って行ってくださる方を探しております。

 

会社の雰囲気やどのような開発環境かもわかるかと思いますので、ぜひ以下のインタビュー記事をぜひご覧ください。

 

 

 

社内ランチLT会始まったぞ!月1開催

はじめに

フロントエンドチームの藤井です。

今月から「社内ランチLT」を開催する運びになり、そのレポートになります!

経緯

以前からちょくちょくと、もっとカジュアルにLTする機会が欲しいと社内で声が上がっていました。

 

そんな中、いつもANDPADの開発を手伝ってくださっている、からまげさん(@kara_mage) からslack上で提案があり開催する運びとなりました。

f:id:yohei-fujii:20190711152210p:plain

 

賛同の声が上がると、その後の企画力は早かったです。概要をポストにまとめてslackで通知。何週間も前から何度もこのポストがチャンネルでシェアされました。(楽しみにしてる感が伝わる・・w)

f:id:yohei-fujii:20190711201019p:plain



 

(ただ、当日ギリギリまで場所を確保していないという致命的ミスが発覚し、開催が危ぶまれましたが、無事フリースペースで行いました)

ランチLTとは

気軽にLTしたい人や参加したい人が、ランチをとりながらカジュアルに行うLTです。普段人前で話す機会がない人や、「外部イベントでの登壇にいきなりはちょっと・・」という人にとって心理的なハードルを下げ、チャレンジするための場にしたいと考えて企画しました。社内限定での開催で、緊張せずに気軽にディスカッションする場です。

やってみた

 まずは、発起人のからまげさんから開催のご挨拶。

f:id:yohei-fujii:20190711152332p:plain

みんな昼飯を準備して参加してます。 リスナーもたくさん集まり、ワイワイとして雰囲気の中開催しました。

 

初回となる今回は、3名によるLTでした。

 

まず、デザイナーの後藤さんから、「これだけ守ればみやすくなるデザインの基礎」解説LT。株式会社Xemonoのとりいめぐみさんの公開されていらっしゃるスライドを使っって「デザインとはなんぞや」というところを説明してくださいました。

 

次に私の「1人1人が楽しくより成長するために ~ 『エンジニアの生産術』を読んでみて」という内容での紹介。

 

そして最後に、SREからフロントに越境している須恵さんによる「Dockerの基本概念」の紹介でした。

 

f:id:yohei-fujii:20190711152342p:plain

 

ゆるくアウトプットの場ということでしたが、私も須恵さんもスライドを作って準備してきたことで、ガチなLTになってしまいました・・。でも、インタラクティブなLTになったし、笑いありと楽しい時間となりました。

 

f:id:yohei-fujii:20190711152346p:plain

 

フリースペースで行ったのですが、途中からエンジニアだけじゃなく、営業さんや他の部署の人たちによる立ち見もできて、盛大なイベントになり嬉しい限りです。

最後に

こんな感じで、初回がうまく行きましたので毎月行うことに決定しました。早速次は8月22日ということです。

 

いろんな人がこういう機会を利用して、アウトプットの練習の場として使っていけるといいですね!

 

もし興味ありましたら、以下のインタビュー記事をぜひご覧ください。会社の雰囲気など分かるかと思います。

 

 

 

ALB Ingress Controllerの使い方

はじめに

SREチームの須恵です。

前回の記事ですこし言及しましたが、今回は続編としてALB Ingress Controllerについて書こうと思います。

これは何?

Amazon EKSでIngressリソースを機能させるために使えるIngress Controllerの一種です。Ingressを作成すると、自動的にALBが作成・設定されます。

github.com

Ingressって何?

公式ドキュメントから引用します。

Ingress - Kubernetes

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

Ingressは、クラスター外からクラスター内のサービスへのHTTPおよびHTTPSルートを公開します。トラフィックルーティングは、Ingressリソースで定義されたルールにより制御されます。

Ingress Controllerって何?

An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.

Ingress controllerはIngressを満たす責任を持ちます。通常はロードバランサーを使いますが、トラフィックを処理するためにエッジルーターや追加のフロントエンドを設定することもできます。

ここからは実際の使い方を紹介します。

IAMポリシー作成

後述のロールにアタッチするためのポリシーを作成します。

サンプルがあるので、とりあえず使い始めてみるときはこれを使わせてもらうとよいと思います。

※リンク先はバージョン1.1.2のサンプルです。使用するコントローラのバージョンとの差異に注意してください。

IAMロール作成

ALB Ingress Controllerに使用させるロールを作成します。

ここで、まずPodに任意のロールを使用させられる環境が必要となります。 手前味噌ですが、以前書いたこちらが参考になると思います。

kube2iamの仕組みと使い方 - Oct Tech Blog

ロールのアクセス権限に関しては先ほどのポリシーをアタッチするだけですが、加えて信頼関係の編集が必要です。以下を追加します。

    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/kubernetes-worker-role"
      },
      "Action": "sts:AssumeRole"
    }

"AWS": "arn:aws:iam::123456789012:role/kubernetes-worker-role"の部分は、使用するワーカーノードに合わせてください。

RBAC用リソース作成

ClusterRole, ServiceAcocunt, 両者を結びつけるClusterRoleBindingを作成します。

サンプル通りで構いません(例によってバージョンには注意、リンク先は1.1.2用)。

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: alb-ingress-controller
  name: alb-ingress-controller
rules:
  - apiGroups:
      - ""
      - extensions
    resources:
      - configmaps
      - endpoints
      - events
      - ingresses
      - ingresses/status
      - services
    verbs:
      - create
      - get
      - list
      - update
      - watch
      - patch
  - apiGroups:
      - ""
      - extensions
    resources:
      - nodes
      - pods
      - secrets
      - services
      - namespaces
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/name: alb-ingress-controller
  name: alb-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: alb-ingress-controller
subjects:
  - kind: ServiceAccount
    name: alb-ingress-controller
    namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/name: alb-ingress-controller
  name: alb-ingress-controller
  namespace: kube-system
...

Deployment作成

コントローラをクラスターで動作させるためのDeploymentを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: alb-ingress-controller
  name: alb-ingress-controller
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alb-ingress-controller
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      annotations:
        iam.amazonaws.com/role: さっき作ったロールのARN
      creationTimestamp: null
      labels:
        app: alb-ingress-controller
    spec:
      containers:
        - args:
            - --ingress-class=alb
            - --cluster-name=クラスターの名前
            - --aws-vpc-id=クラスターVPCのID
            - --aws-region=クラスターのリージョン
            - --aws-api-debug
          image: docker.io/amazon/aws-alb-ingress-controller:v1.1.2
          imagePullPolicy: Always
          name: server
          resources: {}
          terminationMessagePath: /dev/termination-log
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      securityContext: {}
      terminationGracePeriodSeconds: 30
      serviceAccountName: alb-ingress-controller
      serviceAccount: alb-ingress-controller

docker.io/amazon/aws-alb-ingress-controller:v1.1.2 ここは適宜必要なバージョンを指定してください。

PodがAPIサーバーにアクセスする際、先ほど作成したサービスアカウントalb-ingress-controllerを使用するように設定しています。また、アノテーションでは同じく先ほど作成したロールを指定しています。

コントローラは以下の権限でリソースにアクセスを行います。

  • Kubernetesリソースへのアクセスは先ほどのClusterRole
  • AWSリソースへのアクセスは先ほどのIAMポリシー

Deploymentの作成が完了し、Ingress Controllerが動き出したので、Ingressを作成することによりALBを自動設定してアプリケーションへルーティングする準備ができました。

ここからは、簡単な例でアプリケーションへのルーティング方法を紹介します。

ルーティング先アプリケーションの例

重要なのは、タイプをNodePortにするという点です。ALB Ingress Controllerを使用する場合、ServiceはNodePortタイプで作成しましょう。

apiVersion: v1
kind: Service
metadata:
  name: hoge-app
spec:
  selector:
    app: hoge-app
  ports:
  - name: http
    port: 3000
    protocol: TCP
    targetPort: 3000
  type: NodePort

DeploymentやPodのYAMLは割愛しますが、上記の例ではselectorapp: hoge-appとしているので、そのようなラベルが付いている必要があります。

Ingressの作成

下記の例では、80番と443番ポートにリスナーを作成し、80番へのリクエストは443番にリダイレクトするようなルールのALBが作成されます。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress ←複数立てる予定なら区別しやすい名前を付ける
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/subnets: クラスターのサブネットID3つをカンマ区切りで書く
    # HTTPSリスナーを使うなら必要
    alb.ingress.kubernetes.io/certificate-arn: 証明書のARN
    # リスナーのポート番号はここで決める
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    # リダイレクトを使うなら必要
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
spec:
  # ALBのリスナールールと対応
  rules:
  - host: hogeapp.hoge.com
    http:
      paths:
      - path: /*
        backend:
          serviceName: ssl-redirect
          servicePort: use-annotation
      - path: /*
        backend:
          serviceName: hoge-app
          servicePort: 3000

アプリケーションがインターネットに公開され、ブラウザからアクセスできるようになりました。

おわりに

ALB Ingress Controllerを使ってEKS上のアプリケーションへルーティングする方法についてご紹介しました。

採用サイトにて、テクノロジースタックや環境について公開しています。Kubernetesに限らず、ご興味をお持ちいただいた皆様のご応募をお待ちしております。

engineer.88oct.co.jp

デブサミ2019夏の登壇を終えて

はじめに

フロントエンドチームの藤井です。

この度、「Developers Summit 2019 Summer」に行ってきました!4月のRuby Kaigiに次いで、開発部にとっては今年度2回目の大きなイベントへの参加となりましたね。

 

event.shoeisha.jp

 

スポンサーでもあり、登壇セッションもありましたので、数週間前から色々と準備もしておりました! 会場となったのはこちら

 

f:id:yohei-fujii:20190703132159p:plain

 「御茶ノ水ソラシティ」

 

今回のデブサミのテーマは「エンジニア組織とソフトウェアのアーキテクチャを再考する」ですね。オクトもエンジニア組織として拡大しており、ちょうどマッチしたトピックでありました。 

 

f:id:yohei-fujii:20190703105843j:plain

ドドン!

ロゴも上の方にデカデカと掲載して頂きありがたいです!

 

Job Boardなるものもあり、配布資料も貼らせて頂きました。

f:id:yohei-fujii:20190703150537p:plainf:id:yohei-fujii:20190703132147j:plain

(↑ちゃっかり、セッション案内まで書く人事のじっちゃん)

 

セッションの合間合間には、ブースまわりに多くの人が訪れていました。

f:id:yohei-fujii:20190703150849j:plain

 

人気のセッションは、開始前から行列がすごいですね。 

f:id:yohei-fujii:20190703150841j:plain

 

さてそんな中、B会場で15:50からオクトの登壇セッションです。

event.shoeisha.jp

当日までバタバタしならも資料準備でき、いよいよこの日を迎えました。  

f:id:yohei-fujii:20190703105440j:plain

(↑控え室で登壇する3名と共に)

いよいよ登壇の時間

今回は、3名で違った内容を紹介することに。

f:id:yohei-fujii:20190703150835p:plain

(↑セッションで配布した資料と開始前の会場)

 

それぞれがオクトにジョインした時期も違いますし、そのことにも触れてご紹介

f:id:yohei-fujii:20190703153300p:plain

(↑登壇資料p5より抜粋)

 

 1人目:CTO 金近「&ANDPADとは。創業期と世界観

f:id:yohei-fujii:20190703132122j:plain

 

どのような経緯で、施工現場の問題を解決しようという流れになったのか、なぜANDPADが作られることに至ったのかなどです。

 

これは多くの新しい社員にとっても知らなかった内容があったりしたので、資料を社内共有した際に良い反響がありました。こういうイベントがあると言語化して資料にまとめるので、やっぱりいいね!ってなりました。

 

テクノロジーを武器に、社会変革にチャレンジする」というビジョンを掲げていますが、そのためにも「プロダクト構造的マイクロ化」と「組織構造的マイクロ化」というキーワードに触れました。

 

2人目:CMO 山下「エンジニアが開発を最高に楽しむ場を作る」 

f:id:yohei-fujii:20190703132135j:plain

 

「エンジニアにとって『楽しい』とは?」というポイントから入り、オクトにジョインしてから取り組んだこと、そしてその過程で何が楽しいと感じ、何が楽しくないと感じたかなど紹介を紹介しました。

 

普段から個人でもアプリなどの開発を行っておりますし、新規チームでは新しい技術の導入を進めている本人ですので、そのことに触れながら、どういった個人もしくはチームであるのが理想なのかということです。

 

その中で、「フルサイクルエンジニア」に触れました。

実装だけではなく、要件定義やデザイン、テストまで1人で回せるメンバーが集まるチームはお互いカバーしあえますし、サイクルをどんどん回していけるからですね。

 

3人目:PM彌冨「少数精鋭開発から 大人数開発組織への移行」

f:id:yohei-fujii:20190703132129j:plain

 

ここ最近エンジニアの数がどんどん増えている中で、実際にどのような組織づくりをしていっているのかの紹介です。

 

オクトの開発部では「最小マネジメントで自走する組織」かつ「フラットでオープンな組織体制」を目指しております。そのために、活用しているツールであったり、個々人に持ってもらいたい行動規範というものがあります。

 

平常時はティール型組織でありながらも、緊急時にはピラミッド型組織で柔軟に対応するという組織ビジョンもあります。

  

ここまで 簡単に概要のみ紹介しまいたが、こちらが実際に登壇で使用した資料になります。より詳しく知りたい方は、ぜひ目を通してみてください。

 

 

 

登壇後には

登壇が終わると、Ask the speakerという場所に移動して、参加者と名刺交換や交流がありました。「さいきょうのチームをつくる」ということに触れていたので、そのことについて興味を持ってくださった方がいたのは嬉しいですね!

 

f:id:yohei-fujii:20190703132152j:plain


立ち寄ってくださった方々、ありがとうございました!

 

終わってみて

登壇の最初に、「ANDPADをご存知の方いらっしゃいますか?」と質問をしましたが、手が上がったのは数名でした。この事実に、まだまだ認知度低いなと我々みんな感じたのですが、それとともにすぐに「これは伸び代だ!」とポジティブに捉えられていたメンバーはさすがでしたw

 

今後もオクトは様々なイベントに参加して行きます。もし、どこかで見かけたら気軽に声をかけてみてください。

 

積極採用中

弊社では、業務拡大中でエンジニアを積極採用しております。みなさまのご応募お待ちしております!!エンジニア採用サイトに募集職種や、会社の雰囲気の分かるインタビュー記事があります。是非ご覧ください。

 

 

 

kube2iamの仕組みと使い方

はじめに

SREチームの須恵です。 SREとしてはDocker/Kubernetesを利用した環境の整備を主に推進するかたわら、ときおりフロントエンド開発にも自由に挑戦させてもらったりしています。

今回は、kube2iamの仕組みと使い方について書いてみようと思います。

これは何?

kube2iamとは、Amazon EKS上のPodごとにIAMロールを使い分けられるようにするためのツールです。

github.com

なぜ必要?

Amazon EKSにおいて、クラスターを構成するNodeはEC2インスタンスです。

AWSリソースにアクセスするようなPodを動かしたいとき、Podが持てるAWSリソースへの権限は、EC2インスタンスにアタッチされたインスタンスプロファイルに紐づくIAMロールに準じます。

参考) EC2にIAMRole情報を渡すインスタンスプロファイルを知っていますか? | DevelopersIO

ここで、「異なる種類のAWSリソースを使用する複数のPodを、同じクラスターにデプロイしたい」という状況について考えます。

このとき、クラスターのすべてのNodeに 「各Podが必要とする権限の和集合」を許可することになり、 Podが本来権限を持つべきでないリソースに誤ってアクセスできてしまうリスクが生じます。

そのため、「Node単位」でなく「Pod単位」で権限制御できることにニーズがあります。

どうやって実現?

kube2iamが何を行うのか、おおざっぱに説明すると下記です。

kube2iamなし

AWSに対して何かしたいPod

→コンテナが動作するNodeのEC2メタデータAPI

インスタンスプロファイルに紐づくロールの一時クレデンシャルをコンテナに返す

kube2iamあり

AWSに対して何かしたいPod

メタデータAPIへのリクエストをkube2iamコンテナにリダイレクト

→kube2iamが「何かしたいコンテナ」のアノテーションに記述されたロールを引き受け(Assume)

→当該ロールの一時クレデンシャルをコンテナに返す

kube2iamに使用させるIAMロールの作成

ここから実際にkube2iamを利用するための準備を進めます。

まず下記のポリシーを作成します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

次に、「使用サービス:EC2」のロールを作成し、このポリシーをアタッチします。 ロールを作成したら、信頼関係の編集を行います。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/kubernetes-worker-role" ←ここは各自の値
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

"arn:aws:iam::123456789012:role/kubernetes-worker-role" この部分には、ワーカーノード(にアタッチされたインスタンスプロファイル)のIAMロールを記載します。

ここまでの作業で、ワーカーノードに対して、AssumeRoleができる権限だけを与えました。

RBAC用リソース作成

ここからはKubernetesリソースを作成していきます。 まず作成するのはServiceAccount, ClusterRole, ClusterRoleBindingです。

このServiceAccountはkube2iamのPodがKubernetesAPIサーバーにアクセスする際に利用します。

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube2iam
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kube2iam
rules:
  - apiGroups: [""]
    resources: ["namespaces","pods"]
    verbs: ["get","watch","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kube2iam
subjects:
- kind: ServiceAccount
  name: kube2iam
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: kube2iam
  apiGroup: rbac.authorization.k8s.io

DaemonSet作成

ここからは、kube2iamのPodを稼働させるための作業です。

「EC2メタデータAPIへのリクエストを奪取する」という役割を遂行するためには、どのノードでリクエストが発生してもよい=すべてのワーカーノードでkube2iamが動作している必要があるので、DaemonSetリソースを作成します。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube2iam
  namespace: kube-system
  labels:
    app: kube2iam
spec:
  selector:
    matchLabels:
      name: kube2iam
  template:
    metadata:
      labels:
        name: kube2iam
    spec:
      serviceAccountName: kube2iam
      hostNetwork: true
      containers:
        - image: jtblin/kube2iam:latest
          imagePullPolicy: Always
          name: kube2iam
          args:
            - "--app-port=8181"
            - "--auto-discover-base-arn"
            - "--iptables=true"
            - "--host-ip=$(HOST_IP)"
            - "--host-interface=eni+"
            - "--verbose"
          env:
            - name: HOST_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          ports:
            - containerPort: 8181
              hostPort: 8181
              name: http
          securityContext:
            privileged: true

https://hub.docker.com/r/jtblin/kube2iam/ このイメージから起動したコンテナを持つPodが各ノードに配置されます。

privilegedが要る理由

--iptables=trueかつprivileged: trueとすることで、EC2メタデータAPIへのアクセスがkube2iamにプロキシされ、直接EC2メタデータAPIにアクセスしないようにすることができます。

kube2iamを利用してPodでロールを使用する

DaemonSetが作成できたら、任意のロールをPodで使用する準備は完了です。

Podのアノテーションiam.amazonaws.com/roleを追加すると、任意のロールをPodで利用できます。

# Sample
apiVersion: v1
kind: Pod
metadata:
  name: aws-cli
  labels:
    name: aws-cli
  annotations:
    iam.amazonaws.com/role: role-arn ←ここです
spec:
  containers:
  - image: fstab/aws-cli
    command:
      - "/home/aws/aws/env/bin/aws"
      - "s3"
      - "ls"
      - "some-bucket"
    name: aws-cli

最後に

続編として、今回セットアップしたkube2iamともう一つのツールを組み合わせ、EKS上のアプリケーションへALBを使ってルーティングを行う方法について書こうと思います。

SREチームも人が少しずつ増えてきました。

オクトではエンジニアを積極採用中です。ぜひ気軽に採用サイトを見てみてください。

engineer.88oct.co.jp

新横断工程表プロジェクトが始まりました!(Nuxt & TypeScript)

新規プロジェクト本格的に始動

どうも、フロントエンドチームの藤井です。

 

いよいよ、ANDPAD施工管理開発チームの目玉の一つである、「横断工程表」というサービス開発が始まりました。3月にリリースした、案件ごとに作れる「工程表」というサービスをより使いやすく改良したものになります。また、もともとANDPAD本体に入っている「横断工程表」というサービスを作り直すものでもあります。

 

この横断工程表では、案件や担当者、現場などを横断で同じ工程表上で見れることを機能として入れていきます。いわゆるガントチャートのようなサービスですね。

 

Nuxtを採用する理由

旧横断工程表はRails + Angular、工程表はRails + Vueという構成でしたが、今回はフロント側はNuxtで一から作り込むことにしました。

 

理由としては、以下のようなものがあります。

  • バックエンド、フロントのそれぞれの責務がはっきり別れていないのでキャッチアップにも時間がかかる
  • モノリシックな構成のため影響範囲がわかりづらく、毎回リリース前の調査やテストに時間がかかる
  • 本体サービスの週一リリースに合わせるため、ちょっとしたフロント側改修も待たなければならない
  • etc...

 

新工程表プロジェクトからの反省点

また「新工程表」サービス開発からの反省点もあります。

  • なぜこのようなストア設計になっているのかわからない
  • なぜ動いているのかわかりにくいコードがある
  • コンポーネント化を適宜行っていないので、ファイルが肥大化してメンテしにくい
  • グローバルスタイルシートへの依存が多く、まさかのスタイルシートとvueファイルの密結合状態
  • APIエンドポイントがいたるところに転がっている
  • Lintがかかっておらず、無秩序なコードがある
  • etc....

 新プロジェクトでの設定

以上のことを踏まえて、今回のプロジェクトでは環境設定から気をつけました。

  • axios-moduleではなく、axiosを使い、APIエンドポイントを`network/apiClient`に集約
  • assets/cssに最低限のスタイルシート(reset.cssやbase.scss)を先に用意し、新規で作ることを禁止
  • constantsやutils、modelsやdirectivesディレクトリを先に作って、ディレクトリ構成で迷わないように準備
  • Atomic Designを採用し、コンポーネントの管理
  • Lintを導入し、さらにhookを使ってcommit時に自動でlintが走るよう設定
  • TypeScriptを導入し、型を意識した設計にしていく
  • READMEにディレクトリ構成や注意点などを明記しておく
  • etc....

 

様々な人が開発に携わるからこそ、様々なことを明示的に残しておく必要があると感じました。

 

このサービスが日の目を見るのは、7月末ごろでしょうか。これからガンガン開発を行っていきます!

 

最後に

一緒に横断工程表を作ってくれる人を募集しています。こちらに弊社の技術スタックなど載っていますので、ぜひ見てみてください!