はじめに こんにちは。新卒3年目のhy094です。 今回は、先日社内で開催したTypeScript勉強会の資料を公開します。 この資料は、前半は私が作成し後半は一年後輩のたぐち君が作成しています。 TypeScriptとは関係がないですが、たぐち君の記事（note）も紹介しておきます。 デスクトップの整理に悩んでいる方はぜひ見ていってください！ note.com はじめに 前提 資料公開 スライドの中身 参考にさせていただいた書籍・サイト おわりに では、本題に入ります。 前提 TypeScript初心者 向けに作成した資料です JavaScript で書かれたコードのTypeScript移行を目的としています 移行に不要な箇所はあまり触れていません JavaScript の構文も紹介しています 資料公開 スライドの中身 スライドをみる時間がない方向けに、ざっくりどのような内容が書かれているかを記載します。 TypeScriptとは（4〜6ページ） TypeScriptにするメリット 型（8〜19ページ） プリミティブ型 文字列・数値・真偽値・undefined・null (BigInt・シンボルは省略） リテラル 型 object型 オブジェクト リテラル 配列 unknown, any, never ユニオン（合併）型・インターセクション（交差）型 基本的な構文（7,20,21ページ） 演算子 制御構文 関数（22〜26ページ） 関数宣言・アロー関数式 デフォルト引数 可変長引数 this引数 インターフェース（27〜32ページ） type interface 高度な型（33,34ページ） 型ガード 型 アサーション モジュールシステム（35〜39ページ） import・export type宣言 npmパッケージモジュール DefinitelyTyped 自作の型定義ファイル ビルド関連（40〜51ページ） コンパイル ・ コンパイル オプション tsconfig. json webpackタ スクラン ナー webpack.config.js 参考にさせていただいた書籍・サイト 主に以下の書籍・サイトを参考にさせていただきました。その他はスライドに記載しています。 プログラミングTypeScript プロを目指す人のためのTypeScript入門 サバイバルTypeScript これらは個人的に、TypeScriptの参考書3種の神器だと思っています。超オススメです。 おわりに 資料作成に際して、自身の知識がより深まりました。 なんとなく使っていたものを改めて説明するというのは、やはり難しいですね。 ありがたいことに勉強会自体は好評で、録画も社内で見ていただけているようです。 （勉強会後にアンケートを取っており、後日フロントエンドチームのnoteで公開予定です。） 録画の公開はできませんが、資料を見ていただき少しでもTypeScriptへの学びになれば嬉しいです！ フロントエンドチームのnoteです。ぜひご覧ください！ note.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは！株式会社 ラク スの@kzak_24と申します。 インフラ開発部 SRE課に所属しております。 さて今回は、 現在 アサイ ンされている新規システムの開発プロジェクトにて、フロントエンドの技術選定を担当した時の経験 をまとめようと思います。 フロントエンドは未経験だった為、色々と試行錯誤を行いました。 未経験なりにどのような基準を設けて技術選定を行なったか 、皆さまの意思決定の参考になれば幸いです。 目次 SREチームの紹介 前提 チームの背景 検討内容と採用理由 言語 / FW 状態管理 スタイル テスト まとめ 最後に SREチームの紹介 まず始めに、少しだけSREチームについて紹介させてください。 ラク スのSREチームは2021年に発足した比較的新しい組織であり、下記の2つのチームに分かれています。 BP(Business Platform)チーム 社内業務システムの開発/保守/運用をメインに担当するチーム DevOpsチーム プロダクトを横断した自動化や運用改善をメインに担当するチーム 現在BPチームは4名、DevOpsチーム1名で構成されています。 私はBPチームに所属しており、このチームで今回のプロジェクトをスタートさせました。 ラク スのSREチームにご興味ある方は、以下もご参考になさってください。 ・ SREエンジニア | エンジニア職種紹介 | 株式会社ラクス 中途採用 ・ Webアプリケーションエンジニア／Go, TypeScript | エンジニア職種紹介 | 株式会社ラクス 中途採用 前提 今回は、以下のような前提の元で技術選定を行いました。 新規システムとして過去の負債がないまっさらな状態から開発をスタートできる できるだけモダンな技術を使用する（社内の ベンチマーク 的な意味を込めて） 開発するアプリケーションは SPA（Single Page Application） の構成にする 一部ページで SSR （Server Side Rendering）が必要になる チームの背景 バックエンド専門メンバーのみで、フロントエンドの経験は乏しい モダンなフロントエンドの開発経験は、ほぼない これらの前提を踏まえて、今回のプロジェクトにおけるフロントエンドの技術選定については、経験値の低さをカバーすることを重要視し、情報収集のしやすさや学習モチベーションの維持を含めた 「学習コスト」 を最優先することとしました。 また次点で以下の3点を優先することとしました。 社内の利用実績 トレンド 保守性 ※ 2022年 8月 24日 追記 SREチームでフロントエンドの技術選定をしている理由についてのコメントを頂いたので、SREチームの背景を交えて経緯について補足させていただきます。 SREチームの紹介 に記載した通り、BPチームは社内向けの共通基盤の開発・運用を担当しており、アプリケーションエンジニアとしても活動しています。 SREにアプリケーションエンジニアがいる理由は、SREチームが新たなノウハウを各サービスへ展開することをミッションの1つとしている為です。 ラク スではサービスごとに開発チームが存在しており、技術導入なども各チームで判断していますが以下のような課題もあります。 サービスの機能開発と並行稼働の為、導入が思うように進まない そこで、SREチームが社内向けの共通基盤の開発・運用を通し、先行して新しい技術の調査・導入を行うことで、そのノウハウを各サービスに展開し、技術導入を推進するという動きをしています。 その際、以下のように役割分担しています。 BPチーム：技術調査・導入 DevOpsチーム：各サービスへの展開 こういった背景からアプリケーションの開発知識が必要になるので、SREチームにアプリケーションエンジニアが在籍しています。 今回ご紹介するフロントエンドの技術選定は、BPチームの技術調査・導入の活動についての事例となります。 チームの背景 に記載した通り、バックエンド専門のメンバーのみだったので、フロントエンドはフロントエンド専門チームに任せるか？といった議論もありましたが、「過去事例に囚われず、フラットに検討すべき」という判断と「フロントエンドにもチャレンジしたい」という思いから、敢えて自分たちで担当することにしました。 検討内容と採用理由 今回は、以下4つを検討しました。 言語 / FW 状態管理 スタイル テスト 言語 / FW 言語に関しては、近年 デファクトスタンダード になりつつあることと、バックエンド専門で静的型付け言語に慣れているメンバーが多いということで、TypeScriptに決定しました。 また、FWは次の2つから検討しました。 React Vue.js 検討にあたり、判断材料とする為に次のようなことを実施しました。 フロントエンド専門チームへの ヒアリ ング チュートリアル の実践 その結果、今回の選定方針をもとに以下のような比較をすることができました。 React Pros JSX記法のメンバー受けがよく、学習モチベーションが保てそう 関数 コンポーネント 主体で宣言的にかけるので、コードが読みやすく、保守性が高い 直近でリリースした社内の他プロダクトで利用実績がある Cons Vue.jsと比べると学習コストはやや高い ドキュメントの充実度は低い Vue.js Pros 利用者が多く、情報が得られやすいので学習コストが低い 日本語ドキュメントが多い シンプルな設計で拡張性が高い 社内での利用実績がReactより多い Cons SFC 記法のメンバー受けがよくなく、学習モチベーションは低い 世界的なトレンドはReactに劣る 決定内容と理由 決定内容 Reactを採用する 理由 チーム内での評判がよく、モチベーション高く学習を続けていくことができると考えました。 また、保守性の高さや コンポーネント の再利用性もReactの方がチーム内での評価が良かったことも理由です。 Reactを採用するにあたり、 SSR の実現の為に Next.js も採用しました。 状態管理 状態管理に関しては、Reactを使用することを前提として代表的なライブラリである下記の3つから検討しました。 Redux Recoil React Context 状態管理のライブラリについては、主に公式ドキュメントやWebの記事などから情報を収集し、比較検討を行いました。 Redux Fluxベースの状態管理ライブラリです。 Pros 柔軟性が高い Reduxが定めるベストプ ラク ティスのRedux ToolKitがある 1つのグローバルなストアにStateを保持するので管理が容易 Cons 学習コストが高い 今回のプロジェクトで開発するアプリケーションにはToo Muchである Recoil Meta社製の状態管理ライブラリです。 Pros Atom という単位で一意なキーをもったグローバルStateを保持するので、理解しやすい 学習コストが低い割に、機能的には十分 Cons Atom が増えすぎると管理が難しくなる まだメジャーバージョンリリースしていない（執筆時点でのLatestはv0.7.5） React Context Reactが標準で提供しているContext API です。 Pros React標準なので、導入ハードルが低い Hooks（ useContext ）が提供されているので、使い勝手が良い Cons 管理するStateが増えてくるとProviderのネストが深くなり、視認性が悪くなる 祖先 コンポーネント まで辿ってツリーを更新する為、頻繁に レンダリング が発生してしまう 決定内容と理由 決定内容 Recoilを採用する 理由 今回開発するアプリケーションの規模から、ReduxではToo Much、React Contextでは若干不足と考えたので、Recoilを採用しました。 また、基本的に Atom をHooksで操作するだけのシンプルさや学習コストの低さも魅力的でした。 メジャーバージョンのリリースはまだでしたが、実際にプロダクション利用している他社事例もあった為、その点に関しては問題なしと判断しました。 スタイル スタイルに関しては、まず CSS の管理方法について、次のような思いがありました。 CSS に詳しいメンバーがいない為、なるべく CSS ファイルの管理は避けたい スコープはできるだけローカルに閉じて、堅牢性をあげたい 上記の思いを踏まえつつ、方針を考慮した結果、下記の2つから検討しました。 CSS Module styled-components（CSS in JS） 簡単なプロトタイプを実装し、使い勝手や学習コストを比較検討しました。 CSS Modules CSS ファイルをJSからimportしてスタイルを当てる手法です。 Next.jsでは標準でサポートされています。 Pros Next.jsに標準でサポートされている為、導入コストが低い コンポーネント 単位でスコープを閉じられる Cons CSS ファイルを管理することになる 社内に利用実績がない styled-components CSS in JSのライブラリです。 Pros コンポーネント のコードと同居させられるので、スコープについてほぼ考えなくて良い 直近でリリースした社内の他プロダクトで利用実績がある Cons コンポーネント に依存したカスタマイズをするので、移行が難しい 静的な CSS よりもパフォーマンスが低い 決定内容と理由 決定内容 styled-components（ CSS in JS）を採用する 理由 JSファイル内に CSS を記述できるため、以下の通り前提の思いを2つともクリアできる点が決め手でした。 スコープについてほぼ考えなくて良くなる CSS ファイルを作成しなくても良い また、社内でも利用実績があり、情報収集の容易さという点でもメリットがありました。 テスト 最後にテストに関してですが、まずフロントエンドのテスト方針をどのように設定すべきか全く知識がなかった為、社内のフロントエンドチームに ヒアリ ングしました。 そこで Testing Trophy の考え方を教えていただきました。 Testing TrophyとはReact Testing Libraryの作者であるKent C. Dodds氏が提唱する JavaScript のテスト方針です。 今回はその考えに則り、Unit Test及びIntegration Testの層を厚くする方針としました。 その前提の元、テストライブラリは下記の2つを検討しました。 React Testing Library Enzyme テストランナーについては、ほぼ デファクトスタンダード になってきていると思われることと、Next.jsに標準で組み込まれていることから、 Jest を採用しました。 テストは、スタイルの検討の際に実装していたプロトタイプの中で使用し、使い勝手や学習コストを比較検討しました。 React Testing Library Kent C. Dodds氏によるReactテストライブラリです。 Pros Next.jsの 公式ドキュメント でJestと合わせた構成が推奨されている 実際にユーザーにどう見えるかを基準にしたBDD寄りの考え方がチーム内で評判が良い スナップショットテストを実施でき、改修時のリスクを減らせる 直近でリリースした他プロダクトで利用実績がある Cons Enzymeに比べるとコードの記述量が多い Enzyme Airbnb 社製のReactテストライブラリです。 Pros shallow renderのテストは書きやすい コードの記述量は比較的少なくできる コンポーネント のpropsやstateに直接アクセスできる Cons ユーザー目線ではないテストができ上がりがち 決定内容と理由 決定内容 React Testing Libraryを採用する 理由 ユーザーにどう見えるかを基準にしたBDD寄りの方針で作られています。 そのため、本質的なテストをすることができる点に関して、チーム内で評価されたことが決め手でした。 また、関数などのUnit TestはJestで、 コンポーネント 同士のIntegration TestはReact Testing Libraryでという明確な使い分けができ、Unit Test、Integration Testを充実させるテスト方針とマッチすると考えました。 まとめ 最終的に今回採用した技術は以下になります。 言語 / FW 状態管理 スタイル テスト ・TypeScript ・React ・Next.js ・Recoil ・styled-components（ CSS in JS） ・Jest ・React Testing Library 最後に 最後までご覧いただきありがとうございます。 今回は、フロントエンド未経験のSREエンジニアが技術選定を担当した経験についてご紹介しました。 技術選定はシステム要件、チームの背景、スケジュールなど様々な要因を考慮する必要があり、非常に良い経験となりました。 SREチームではフロントエンドだけではなく、バックエンドではGoを使用した フルスクラッチ 開発や、 AWS EKSを使用した Kubernetes 基盤の構築など様々な取り組みを進めております。 今回紹介したこと以外にもたくさんの情報を発信していけるように、今後も取り組んで参ります。 ◆ 直近で開催予定の採用イベントをご紹介！ career-recruit.rakus.co.jp career-recruit.rakus.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに 皆さん、こんにちは、kirrksです。 今回は一度は聞いたことある「プロキシ」について、 プロキシの仕組みや種類 利用するメリット/デメリット 注意点 など、簡単に解説していきます。 この記事を読んで「プロキシ」を少しでも理解して頂ければ幸いです。 目次 はじめに 目次 プロキシとは プロキシの仕組み プロキシのメリット プロキシのデメリット 利用上の注意点 プロキシの種類 まとめ プロキシとは プロキシとは、主に「クライアント」から「サーバ」にアクセスする際、「クライアントの代理」として接続を行うサーバのことを指します。 プロキシ（Proxy）は、直訳で「 代理人 」「代理」「代わり」などの意味を持ちます。 プロキシには、目的別に様々な種類が存在しますが、一般的には利用者（クライアント）とWebサーバの中間でHTTP通信を代理するWebプロキシ（ フォワ ードプロキシ）を指すことが多いです。 プロキシの仕組み これから、プロキシの仕組みについて、「クライアント」から「Webサーバ」へアクセスする流れを用いて見ていきましょう。 なお、ここでは「プロキシサーバを経由しない通信」「プロキシサーバを経由する通信」の流れに分けて確認していきます。 プロキシサーバを経由しない通信 まず、クライアントからWebサーバに通常アクセスする流れです。 クライアント端末のブラウザからサイトをリク エス トする リク エス トがWebサーバに届く Webサーバがリク エス トに対応したページをクライアントへ返す クライアント端末のブラウザにサイトが表示される 以上のように、通常はクライアントが直接Webサーバにリク エス トをします。 プロキシサーバを経由する通信 次に、プロキシサーバを経由してアクセスする流れを見ていきましょう。 クライアント端末のブラウザからサイトをリク エス トする リク エス トをプロキシが受け取る プロキシがWebサーバへリク エス トを送る Webサーバがリク エス トに対応したページをプロキシに返す プロキシはWebサーバから返ってきたページをクライアント端末に渡す クライアント端末のブラウザにサイトが表示される このように、クライアント端末はWebサーバへ直接リク エス トを送るのではなく、プロキシに最初リク エス トを送ります。 上記2つの通信の流れの違いは、以下となります。 プロキシを介している場合、Webサーバはクライアントの情報がわからない Webサーバがわかる情報は、プロキシの情報のみ 以上のように、クライアントからWebサーバへのリク エス トをプロキシが代わりに行っているのです。 プロキシのメリット ここでは、プロキシの利用によるメリットを紹介していきます。 匿名性が確保できる プロキシの利用は、匿名性を確保できることからセキュリティの強化につながります。 クライアント端末から直接Webサーバにアクセスした場合、 IPアドレス などの情報は接続先（Webサーバ）に記録されます。 一般家庭の通信は、接続ごとに IPアドレス が変わるため問題ありません。 しかし、専用回線を使用する企業には、 サイバー攻撃 の可能性があります。 悪意のあるサイトにアクセスした場合、アクセス元を把握され サイバー攻撃 につながる可能性があります。 しかし、プロキシを経由すれば端末は直接接続されないため、情報が接続先に伝わりません。 プロキシ上に アクセスログ が残る プロキシ上にログが残ることも、プロキシサーバを利用する大きなメリットです。 プロキシサーバを使用すれば、どのサイトにアクセスしたのかなどのデータがログに記録されます。 そのため、 どのような人物がどういったサイトを閲覧しているのか 不正なアクセスが行われるのはどこからなのか などの情報を残すことができます。 これらのことを記録しておくことで、万が一 サイバー攻撃 などを受けた場合などにもログを解析することによって適切に対処することが可能になります。 サーバの負担を分散できる サーバの負担を分散できることも、プロキシサーバの大きなメリットです。 特定のサイトへアクセスが集中しないよう、複数サーバへ振り分けることができる「ロードバランシング」という機能を持たせることが可能です。 このような機能によってネットワークやサーバ負担を軽減させることができ、通信速度を向上させる効果もあります。 このように、プロキシサーバはユーザーが快適に利用できる環境を整える役割も担っています。 キャッシュサイト機能で表示の高速化 プロキシにキャッシュが残っていると、コンテンツの表示が早くなることも大きなメリットです。 Webサーバにリク エス トを送信する必要がなくなり、同時にWebサーバからコンテンツを受信する時間も省略することができ、その分だけ表示スピードが早くなります。 ウイルスチェックができる プロキシでは、ウイルスチェックも行うことができます。 クライアント端末ではなく、プロキシ上でウイルスチェックができるため、運用する上でメリットがあるのです。 ウイルスに感染すると、個人情報の流出や様々なトラブルにつながる可能性があります。 個人情報の流出は企業であれば顧客の信頼を一瞬で失ってしまうことになります。 そのようなことを防ぐためにも、ウイルスチェックを行うことが必要です。 対策することによって、社内ネットワークへのウイルスの侵入を未然に防ぐことができ、安全性を向上させることができます。 プロキシのデメリット ここでは、プロキシの利用によるデメリットを紹介していきます。 不正サイトへ誘導される可能性がある プロキシが不正なサイトへの誘導を行ってしまう可能性があることは、デメリットの一つです。 例としては、プロキシに対して攻撃が仕掛けられ、偽のサイトや フィッシング詐欺 などのサイトへ誘導してしまうものなどがあります。 こういった場合にはユーザーのリク エス トとは別のサイトへプロキシが誘導してしまうことになるのです。 それによって、誘導をしたサイトでユーザーの個人情報が抜き取られたり、詐欺に遭うなどの被害をもたらしてしまう危険性があります。 接続履歴が見られる可能性がある プロキシの接続履歴が見られる可能性があることも、デメリットの一つです。 上述したように、プロキシ上には様々なデータ（ログ）が残っているため、攻撃しようとする者によってこれらの情報を見られてしまう危険性があります。 ログを確認されることで、個人情報の漏洩やアクセス履歴から迷惑メールの対象となってしまう可能性もあります。 このように、接続履歴をチェックされるとユーザーにも被害が出る危険性があることは、あらかじめ把握しておく必要があります。 情報が盗まれる可能性がある プロキシを利用すると、サーバを経由してやりとりしている情報を盗まれる可能性があることも、デメリットになります。 例としては、悪意のある人物が意図的にプロキシを設置した場合や、 ハッカー によってハッキングされたような場合にはアクセスの際に送受信した情報を抜き取られることもあり得ます。 このような情報には様々な個人情報が含まれている場合も多く、ユーザーに被害がおよぶ危険性があります。 利用する際にはサーバだけではなく、アクセス先のセキュリティ対策がしっかり行われているかどうかについてもよく確認しておきましょう。 サイトによっては通信速度が低下する プロキシのメリットに表示速度の速さをあげましたが、それはキャッシュが残っているときの話です。 キャッシュのない場合には、通信速度が遅くなる可能性があります。 利用上の注意点 ここでは、プロキシを利用する際の注意点を紹介していきます。 安全な非公開プロキシを利用する 誰でも利用できるプロキシサーバを公開プロキシと言います。 公開プロキシには、利用者の個人情報を抜き取る「悪意のあるプロキシ」を設置している可能性があります。 プロキシサーバを利用する際は、信頼できる提供元の非公開プロキシを利用するようにしましょう。 認証設定を行う プロキシサーバを購入し、自分で構築したい人は、必ずIDとパスワードによる認証を有効化しておきましょう。 もし、有効化を怠ると、誰でもアクセスできる状態になります。 不特定多数が利用できるプロキシサーバはリスクが高く、ウイルス感染、 個人情報流出 、サイバー犯罪のアクセス経路に利用されてしまいます。 必要な場合に限り使用する プロキシサーバは必ず使用しなくてはいけないものではありません。 どうしても必要なときだけ利用するようにしましょう。 それだけで個人情報漏洩や悪意ある サイバー攻撃 を受けてしまうリスクを減らすことができます。 プロキシの種類 ここでは利用目的により、種類が異なるプロキシを簡単に紹介していきます。 フォワ ードプロキシ Webプロキシサーバとも呼ばれ、クライアントとWebの間に設置し、利用者側に位置しています。 ファイアウォール によるアクセス制限の際に、外部ネットワークへの接続を目的として利用される傾向が多いです。 リバースプロキシ 「逆プロキシ」とも呼ばれ、利用者とWebの間に設置しますが、 フォワ ードプロキシとは異なり、Webサーバ側に位置します。 主にWebサーバの負荷軽減を目的としています。 透過型プロキシ ネットワーク側の特定ポートに向けて設置するプロキシです。 利用者は、通信の迂回路を作成できないため、他のネットワークの使用ができません。 端末でプロキシを設定しなくても適用できるため、従業員が多い企業で利用されるのが一般的です。 キャッシュサーバ プロキシには、インターネット接続の際にデータをキャッシュとして保管する機能があり、２回目以降に同じサーバへアクセスする際は、高速でサイトが表示されます。 さらに、同じプロキシを利用している端末が１度でもサイトにアクセスすれば、それ以外のユーザーも高速で接続できます。 まとめ いかがでしたでしょうか？ 今回はプロキシについてご紹介させていただきました。 プロキシの役割が少しでもわかったのではないでしょうか。 改めまして、本記事がITを学ぶ方にとって、少しでもお役立ちできれば幸いです。 最後までお読みいただきありがとうございました。 参考 プロキシとは？仕組みやメリットからプロキシの種類までを解説！ | IT SPice | CTCエスピー（株） プロキシとは？主なメリットやデメリット、注意点 から種類まで徹底解説！ | ITトレンド プロキシサーバとは？仕組みやメリット・デメリットを詳しく解説！ | DIGITAL SHIFT TIMES エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに 皆様こんにちは。 インフラ開発課でインフラエンジニアとして勤務しておりますryskwです。 ラク スではメールを主に扱うサービスが多くあります。 そのため、メールに関する知識は業務に欠かせないものとなっています。 今回は、そんなメールに関する ソフトウェアとして有名な Postfix （ポストフィックス） を取り上げたいと思います。 本記事を読むことで、 Postfix を使用したメールサーバの基本的な構築をしたいという方 のお役に立てれば幸いです。 目次 はじめに 目次 Postfixとは Postfixのインストール Postfixの設定 設定ファイルのバックアップ Postfixで使用するドメイン名の指定 Postfixで使用するインターフェースの指定 Postfixで拒否したいメールの設定 Postfixのバージョン非表示設定 Postfixでメール送信 おまけ FromアドレスとエンベロープFrom メール受信にはDovecot 最後に 参考 Postfix とは Postfix は フリーソフトウェア のメール転送エージェント（MTA）であり、 Linux などの UNIX 系システムで実行されます。 UNIX で古くから使用されてきた Sendmail に代わるものとして開発されたようです。 Postfix のホームページでは Sendmail ライクに見えますが、より安全、高速、設定しやすいことなどをメリットとして挙げています。 ※メール転送エージェントとは、メールの配送（送信）を行うメールサーバ 　（ SMTP サーバと言ったりもしますね）の中で、文字通りメールの転送を担うプログラムです。 　受信したメールを相手方に送信する（振り分ける）メールサーバの中でも中心的な役割を持っています。 また、メールサーバと言うと送受信できるようなイメージを持ちますが、実際にはメール受信には受信用のサーバが必要となります（POPサーバや IMAP サーバ）。 Postfix は受信サーバとしての役割はないため、受信用サーバを構築したい場合は、別途ソフトウェアを併せてインストールする必要があります。 Postfix のインストール それでは、 Postfix を利用したメールサーバの構築を実際に行ってみましょう。 Postfix は UNIX 系のOSで動作するため、本記事では Linux OSの中から Alma Linux を使用してインストールしていきます。 ホスト名は smtp.test.hdomain としています。 [ root@smtp ~ ] # cat /etc/redhat-release AlmaLinux release 8 . 5 ( Arctic Sphynx ) [ root@smtp ~ ] # uname -a Linux smtp. test .hdomain 4 . 18 .0-348.el8.x86_64 #1 SMP Tue Nov 9 06:28:28 EST 2021 x86_64 x86_64 x86_64 GNU/Linux [ root@smtp ~ ] # では、 Postfix をインストールしていきましょう。 AlmaLinux 8.5 では、標準でバージョン 3.5.8-4 の Postfix がインストールされるようです。 yum install コマンドで Postfix のインストールを行います。 [ root@smtp ~ ] # yum install postfix メタデータの期限切れの最終確認: 0:02:01 時間前の 2022 年 08 月 08 日 23 時 36 分 39 秒 に実施しました。 依存関係が解決しました。 ============================================================================================================================================================================================================================================= パッケージ アーキテクチャー バージョン リポジトリー サイズ ============================================================================================================================================================================================================================================= インストール: postfix x86_64 2:3. 5 .8-4.el8 baseos 1 . 5 M 依存関係のインストール: libicu x86_64 60 .3-2.el8_1 baseos 8 . 8 M トランザクションの概要 ============================================================================================================================================================================================================================================= インストール 2 パッケージ ダウンロードサイズの合計: 10 M インストール後のサイズ: 37 M これでよろしいですか? [ y/N ] : y パッケージのダウンロード: ( 1 / 2 ) : postfix-3. 5 .8-4.el8.x86_64. rpm 9 . 4 MB/s | 1 . 5 MB 00:00 ( 2 / 2 ) : libicu-60.3-2.el8_1.x86_64. rpm 16 MB/s | 8 . 8 MB 00:00 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 合計 6 . 8 MB/s | 10 MB 00:01 AlmaLinux 8 - BaseOS 2 . 8 MB/s | 3 . 4 kB 00:00 GPG 鍵 0xC21AD6EA をインポート中: Userid : " AlmaLinux <packager@almalinux.org> " Fingerprint: E53C F5EF 91CE B0AD 1812 ECB8 51D6 647E C21A D6EA From : /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux これでよろしいですか? [ y/N ] : y 鍵のインポートに成功しました トランザクションの確認を実行中 トランザクションの確認に成功しました。 トランザクションのテストを実行中 トランザクションのテストに成功しました。 トランザクションを実行中 準備 : 1 / 1 インストール中 : libicu-60.3-2.el8_1.x86_64 1 / 2 scriptletの実行中: libicu-60.3-2.el8_1.x86_64 1 / 2 scriptletの実行中: postfix-2:3. 5 .8-4.el8.x86_64 2 / 2 インストール中 : postfix-2:3. 5 .8-4.el8.x86_64 2 / 2 scriptletの実行中: postfix-2:3. 5 .8-4.el8.x86_64 2 / 2 検証 : libicu-60.3-2.el8_1.x86_64 1 / 2 検証 : postfix-2:3. 5 .8-4.el8.x86_64 2 / 2 インストール済み: libicu-60.3-2.el8_1.x86_64 postfix-2:3. 5 .8-4.el8.x86_64 完了しました! [ root@smtp ~ ] # これで無事インストールが完了しました！ Postfix の設定 続いて Postfix の基本的な設定を行っていきます。 Postfix の基本の設定を行うには、 /etc/postfix/main.cf という設定ファイルがあるので、そのファイルで必要となるパラメータを定義していきます。 ここでは、検証環境を構築する上で必要最低限となる設定のみ取り扱っています。 もし必要があれば Postfix のホームページからより細かな設定について記載がありますので、そちらもどうぞご確認ください。 設定ファイルのバックアップ では、 Postfix の設定ファイルを修正していきましょう。 まずは、元の設定ファイルのバックアップを取得しておきましょう。 [ root@smtp ~ ] # cp -p /etc/postfix/main.cf /etc/postfix/main.cf.org [ root@smtp ~ ] # ls /etc/postfix/main.cf.org /etc/postfix/main.cf.org [ root@smtp ~ ] # 設定ファイルを修正していきます。 [ root@smtp ~ ] # vi /etc/postfix/main.cf Postfix で使用する ドメイン 名の指定 まずは myhostname という設定を探しましょう。 ドキュメントには Postfix をインストールしたマシンの完全修飾 ドメイン 名（いわゆる FQDN ）を指定する、とあります。 94～95行目に設定が記載されていると思いますので、その下に新たに Postfix をインストールしたマシンのホスト名を追記しましょう。myhostnameを設定することでメールアドレスの@マーク以降に入る ドメイン を指定できます。 #myhostname = host.domain.tld #myhostname = virtual.domain.tld myhostname = smtp.test.hdomain →　追記した設定 あるいは、 mydomain という設定で ドメイン 名を設定することもできます。 mydomainに ドメイン 名を指定しておくことで、main.cf内でmydomainが変数のように扱われ、それを元にmyhostnameで FQDN を生成することができます。 今回構築している検証環境を例に挙げると smtp ： ホスト部 test.hdomain： ドメイン 部 となるため、mydomainにはtest.hdomainを記載します。 恐らく、デフォルトの設定ファイルでは102行目あたりに記載があるはずです。 #mydomain = domain.tld mydomain = test.hdomain →　追記した設定 次にメールの配送先の指定を行います。 mydestination では別のサーバではなく､ Postfix をインストールしているマシンに配信する際の ドメイン を指定します。 サーバでは大抵rootユーザ宛などシステムメールが配信されていたりするため、ローカルで配信されるメールの配送先として自身のホスト名を指定しておきます。 構築するサーバが ドメイン 全体のメールサーバである場合は「mydomainもリストする必要がある」、とドキュメントに記載されておりますので、ここは後々のことも考えてデフォルトで指定されている設定は コメントアウト し、mydomainも指定されているものをアンコメントして有効化しておきましょう。 #mydestination = $myhostname, localhost.$mydomain, localhost →　デフォルトではここが有効になっているためコメントアウト mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain →　mydomainがリストされているこの行を有効化 #mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, # mail.$mydomain, www.$mydomain, ftp.$mydomain Postfix で使用するインターフェースの指定 続いて、 Postfix がメールを受信する際のインターフェースを設定しましょう。 デフォルトではローカルホストのみとなっているため、外部からのメールを受け取れないようになっています。 inet_interfaces の設定でローカルホストだけでなくすべてのネットワークインターフェース（このサーバが持つ IPアドレス ）で受信が可能となるように、以下のように設定を変更しておきしょう。 ※より安心な設計として、main.cfはデフォルトの設定のままにしておき、 　master.cfという設定ファイルで明示的に IPアドレス を指定する、という方法もあります。 　しかしながら、今回はmain.cfを主に修正しているのでこの方法で進めます。 inet_interfaces = all →　この行を有効化 #inet_interfaces = $myhostname #inet_interfaces = $myhostname, localhost #inet_interfaces = localhost →　デフォルトではここが有効になっているためコメントアウト Postfix で拒否したいメールの設定 安心なメールサーバ構築のためには、意図しない ドメイン へメールを送らないように設定しなればなりません。 もしも他人が使用できるグローバルな環境で、どの ドメイン にも送れてしまうようなメールサーバを構築してしまった場合、 スパムメール を送るリレーサーバとして悪意あるユーザから悪用されてしまうことが考えられます。 そこで、 Postfix の設定の中に、これまで設定してきた ドメイン やホスト名に合致しない宛先にメールを送ろうとした場合に拒否する設定がありますので、そちらも設定しておきます。 local_recipient_maps という設定に有効な受信者としての ドメイン をリストしておくことで、受信者チェックを行いmydestinationなどで設定した ドメイン に一致しないローカルユーザへのメールを拒否することができます。 デフォルト設定から触らなくとも問題はないですが、わかりやすいので明示的にアンコメントして有効化しておきましょう。 local_recipient_maps = unix:passwd.byname $alias_maps →　この行を有効化 #local_recipient_maps = proxy:unix:passwd.byname $alias_maps #local_recipient_maps = Postfix のバージョン非表示設定 さて、 Postfix を使用してメールサーバを構築する準備をしてきましたが、あらゆるソフトウェアには将来的に 脆弱性 が生じる可能性があります。 どのソフトウェアのどのバージョンを使用してサーバが構築されているか、ということが知られてしまうと、そのソフトウェアやバージョンに 脆弱性 があった場合、外部公開しているサーバの 脆弱性 を攻撃されてしまうことで何らかの影響が生じてしまう可能性があります。 そのため、基本的には使用しているソフトウェアは外部から接続された場合にバージョンがわからないようにしておくことがベストです。 どのバージョンの Postfix を使用しているかが外部にわからないように、 Postfix への接続時にバージョン情報が表示されないよう、以下を設定しておきましょう。 #smtpd_banner = $myhostname ESMTP $mail_name #smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) smtpd_banner = $myhostname ESMTP $mail_name unknown →　追記した設定 また、 Postfix を使用してメールの送信した記録をログファイルで確認したい時があると思いますので、最後にログの設定をしておきます。 main.cfの末尾に、以下のように追記することで、 /var/log/maillog にログが残るようにします。 syslog_facility = mail 以上で、 Postfix の基本的な設定は完了です。 少し長かったでしょうか。お疲れ様でした。 最後に Postfix を再起動して設定完了です。 [ root@smtp ~ ] # systemctl restart postfix [ root@smtp ~ ] # systemctl status postfix ● postfix.service - Postfix Mail Transport Agent Loaded: loaded ( /usr/lib/systemd/system/postfix.service ; disabled ; vendor preset: disabled ) Active: active ( running ) since Wed 2022-08-10 16:11:24 JST; 7s ago Process: 15565 ExecStart =/usr/sbin/postfix start ( code =exited , status = 0 /SUCCESS ) Process: 15563 ExecStartPre =/usr/libexec/postfix/chroot-update ( code =exited , status = 0 /SUCCESS ) Process: 15559 ExecStartPre =/usr/libexec/postfix/aliasesdb ( code =exited , status = 0 /SUCCESS ) Process: 15557 ExecStartPre =/usr/sbin/restorecon -R /var/spool/postfix/pid/master.pid ( code =exited , status = 255 ) Main PID: 15634 ( master ) Tasks: 3 ( limit: 10645 ) Memory: 5 .1M CGroup: /system.slice/postfix.service tq15634 /usr/libexec/postfix/master -w tq15635 pickup -l -t unix -u mq15636 qmgr -l -t unix -u 8 月 10 16:11:23 smtp. test .hdomain systemd [ 1 ] : Starting Postfix Mail Transport Agent... 8 月 10 16:11:23 smtp. test .hdomain restorecon [ 15557 ] : /usr/sbin/restorecon: lstat ( /var/spool/postfix/pid/master.pid ) failed: No such file or directory 8 月 10 16:11:24 smtp. test .hdomain postfix/master [ 15634 ] : daemon started -- version 3 . 5 . 8 , configuration /etc/postfix 8 月 10 16:11:24 smtp. test .hdomain systemd [ 1 ] : Started Postfix Mail Transport Agent. [ root@smtp ~ ] # 問題なく起動していればOKです。 Postfix でメール送信 それでは、基本的な設定が終わったのでメールの送信をしてみましょう！ 今回は、構築したサーバとは別にメールを受信できるサーバを用意しました。 また、「ryskw」というユーザを用意したので、そのユーザ宛にメールを送信してみます。 以下のように sendmail コマンドでメールを送信してみましょう。 [ root@smtp ~ ] # sendmail ryskw@ [ 送信先のホスト名 ] .hdomain →　送信先のメールアドレス。 [ ユーザ名 ] @ [ 送信先のサーバ ] となる From:ryskw@smtp. test .hdomain →　送信元のメールアドレス To:ryskw@ [ 送信先のホスト名 ] .hdomain →　送信先のメールアドレス Subject:Postfix test →　メールの件名 test →　メールの本文 . →　本文を書き終えたら「.」を打ってEnter [ root@smtp ~ ] # これでメールが送信されたはずです。 Postfix の設定でメールの送信ログが /var/log/maillog に出力されるように設定したので、ログを確認してみましょう。 [ root@smtp ~ ] # cat /var/log/maillog ------------以下のようなログがあればok------------ Aug 10 17:45:03 smtp postfix/pickup [ 15635 ] : 1CEAB1002B7E: uid = 0 from = < root > Aug 10 17:45:03 smtp postfix/cleanup [ 15677 ] : 1CEAB1002B7E: message-id =< 20220810084503 .1CEAB1002B7E@smtp. test .hdomain > Aug 10 17:45:03 smtp postfix/qmgr [ 15636 ] : 1CEAB1002B7E: from = < root@smtp. test .hdomain > , size = 317 , nrcpt = 1 ( queue active ) Aug 10 17:45:03 smtp postfix/smtp [ 15679 ] : 1CEAB1002B7E: to = < ryskw@xxxxxxxxxxxx.hdomain > , relay =xxxxxxxxxxxx.hdomain [ 172 . 20 . 100 . 114 ] :25, delay = 91 , delays = 90 / 0 . 03 / 0 . 21 / 0 . 17 , dsn = 2 . 0 . 0 , status= sent ( 250 2 . 0 . 0 Ok: queued as 71384C0045 ) Aug 10 17:45:03 smtp postfix/qmgr [ 15636 ] : 1CEAB1002B7E: removed 無事送信できていることが確認できました！ ちなみに、メールを受信したサーバ側で確認すると、以下のようにメールが表示されました。 Return-Path: < root@smtp. test .hdomain > X-Original-To: ryskw@xxxxxxxxxxxx.hdomain Delivered-To: ryskw@xxxxxxxxxxxx.hdomain Received: from smtp. test .hdomain ( unknown [ 172 . 20 . 100 . 104 ] ) ( using TLSv1. 2 with cipher ADH-AES256-GCM-SHA384 ( 256 / 256 bits )) ( No client certificate requested ) by xxxxxxxxxxxx.hdomain ( Postfix ) with ESMTPS id 71384C0045 for < ryskw@xxxxxxxxxxxx.hdomain >; Wed, 10 Aug 2022 17:45:06 + 0900 ( JST ) Received: by smtp. test .hdomain ( Postfix, from userid 0 ) id 1CEAB1002B7E ; Wed, 10 Aug 2022 17:45:03 + 0900 ( JST ) From:ryskw@smtp. test .hdomain To:ryskw@xxxxxxxxxxxx.hdomain Subject:Postfix test Message-Id: < 20220810084503 .1CEAB1002B7E@smtp. test .hdomain > Date: Wed, 10 Aug 2022 17:43:32 + 0900 ( JST ) test ※送り先のサーバについては諸事情あって xxxxxxxxxxxx.hdomain とホスト名を伏せさせていただきました。 ちゃんと送信元サーバで入力した内容が送られてきています。 これで、 Postfix をインストールした環境でメールが送信できることが確認できました！ おまけ Fromアドレスと エンベロープ From sendmail コマンドでメールを送信した際に指定したFromアドレスが ryskw@smtp.test.hdomain にも関わらず、maillog内や受信したメールのヘッダー内にあるReturn-Pathには root@smtp.test.hdomain とあります。 これは Postfix を利用してメールを送信したとき、送信元のサーバではrootユーザで作業したからなのですが、メール内のFromアドレスには ryskw@smtp.test.hdomain と、コマンドで指定したものが入力されています。 メールに表示されているFromアドレス（ヘッダFrom）と異なっていますが、こちらは エンベロープ Fromと呼ばれるアドレスとの違いになります。 この違いはしばしば、封筒に書かれた差出人や住所の情報（ エンベロープ From）と、封筒内の便箋に書かれた差出人の名前の違いに例えられます。 詳細は割愛しますが、メール送信時にチェックされるのはこの エンベロープ Fromのみであり、Fromアドレスのほうはチェックされません。 にも関わらず、メールを受信したときに送信元として表示されるのはこのFromアドレスの方なので、実際の送り主とは異なる人がなりすますこともできてしまう、という問題点があります。 そのため、メールを受信した場合にはなりすましに注意しましょう、ということがよく言われます。 メール受信には Dovecot ここまで Postfix を使用してメールを送信する環境を構築してきましたが、メールを受信する環境については別のサーバを構築していました。 また、そちらのサーバではメール送信用の Postfix と併せて、メールを受信するための機能を持つ Dovecot （ダヴコット）というソフトウェアをインストールして構築しました。 機会があれば Dovecot のインストールについてもいずれ記事を作ることができれば、と思います。 最後に いかがだったでしょうか。 Postfix を使用すれば簡単にメールサーバができるんじゃないかと思います。 認証などの機能についても導入することができるため、より安全なメールサーバを自力で構築することも可能ですので、是非お試しください。 それでは、ご覧いただきありがとうございました。 参考 Postfix公式ホームページ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに はじめまして、disk-bugと申します。 今回は、 k8s 初心者な私が開発環境にkindを利用して k8s クラスタ を構築し、その クラスタ 上でArgoWorkflowsを動かすことができましたので、 k8s 上にArgoWorkflowsが構築できるまでのお話をしたいと思います。 目次 はじめに 目次 k8sとは？ kindとは？ ArgoWorkflowsとは？ kindを使ってk8sクラスタを構築してみる シングルノードクラスタ作成 マルチノードクラスタ作成 アプリケーションをデプロイしてみる アプリケーションをスケールする アプリケーションに外部から接続する(NodePort Service) アプリケーションに外部から接続する(Ingress) ArgoWorkflowsの導入 まとめ k8s とは？ Kubernetes ( k8s )は、デプロイやスケーリングを自動化したり、コンテナ化されたアプリケーションを管理したりするための、 オープンソース のシステムです。 Kubernetes を利用することで、手動デプロイを無くし、高負荷状態になった時のスケーリングやヘルスチェックによる自動復旧などができるようになります。 そもそも Kubernetes の読み方についてですが、 「クバネティス」「クバネテス」「クーベネティス」、色々と読み方があるようです。 他にも k8s やkubeとも呼ばれていますが、本記事では k8s (ケーエイツ、ケーハチ エス )と以下呼ぶようにします。 なぜ k8s なのかというと、 K+8文字+s だからなんだそうです。 kindとは？ k8s が便利そうなのはわかったけど、実際どんな感じか動かしてみたいですよね。 k8s の公式ドキュメントに 各種ツールが紹介されており 、ローカル上で実行するツールも紹介されています。 Minikube と kind が紹介されていますが、kindの説明に 1種類のコンテナランタイム上で動作 との記載があり軽量に動かせそうなのかなと思いました。 よって、今回はkindを選択しました。 kindの公式ドキュメントの説明でも、 Dockerコンテナのノードを利用して、ローカル上で k8s クラスタ を実行するためのツールになります。 と紹介されているのでDocker上で k8s クラスタ が構築できるようです。 ArgoWorkflowsとは？ k8s 上で何か動かしたいですよね。 もともとチーム内で新しいPipelineツールの検討を行っていたので、 k8s 上で動かせるArgoWorkflowsに目をつけました。 ArgoWorkflows とは、 k8s でジョブを調整するための OSS のコンテナーネイティブワークフローエンジンです。 Argoと聞くと ArgoCD を思い浮かべる方が多いと思いますが、ワークフローエンジンも提供しています。 今までPipelineやJobを実行するツールと言えばJenkinsくらいしか使ってこなかったので、 k8s に加えてArgoWorkflowsという新しい技術への挑戦となりました。 kindを使って k8s クラスタ を構築してみる では実際にkindを使って、 k8s クラスタ を構築してみます。 kindの QuickStart を参照して、まずは自身の端末に kind コマンドをインストールします。 MacOS を使っていますので、以下コマンドでインストールしました。 $ brew install kind $ kind --version kind version 0 . 14 . 0 シング ルノー ド クラスタ 作成 kind コマンドがインストールできましたので、 k8s クラスタ を構築してみます。 以下コマンドで k8s クラスタ が構築できるようですが、エラーが発生しました。 $ kind create cluster ERROR: failed to create cluster: failed to list nodes: command " docker ps -a --filter label=io.x-k8s.kind.cluster=kind --format '{{.Names}}' " failed with error: exit status 1 Command Output: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 初歩的なミス・・・Dockerを起動してませんでした。 DockerDesktopを起動して、再度コマンド実行します。 $ kind create cluster Creating cluster " kind " ... ... Set kubectl context to " kind-kind " k8s クラスタ が構築できたので確認します。 $ kind get clusters kind kind という k8s クラスタ が作成されました。 k8s クラスタ を制御できる kubectl というコマンドがあるので、インストールして作成した k8s クラスタ を確認してみましょう。 $ brew install kubectl ... $ kubectl cluster-info --context kind-kind Kubernetes control plane is running at ... ... kubectl コマンドで k8s クラスタ が確認できました。 ここで、今更ながら k8s クラスタ とは何でしょうか？ k8s クラスタ とは、コンテナ化されたアプリケーションを実行するためのサーバー群のことです。 そしてサーバー( VM や物理的なマシン)のことをノードと呼びます。 ノードは以下2種類です。 ワーカーノード：コンテナ化されたアプリケーションを実行する環境 マスターノード：コンテナ化されたアプリケーション環境を管理する環境 何を管理するのかというと、 目的の状態になっているのか？ 具体的にはアプリケーションが生きているか？ 必要なアプリケーション数になっているか？ などなど、現在の状態から目的の状態になるように管理します。 kindで構築した k8s クラスタ のノードを確認してみましょう。 $ kubectl get node NAME STATUS ROLES AGE VERSION kind-control-plane Ready control-plane 5m6s v1. 24 . 0 $ kubectl describe node kind-control-plane Name: kind-control-plane ... $ docker container ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 118df6a43f45 kindest/node:v1. 24 . 0 " /usr/local/bin/entr… " About a minute ago Up About a minute 127 . 0 . 0 .1:54251- > 6443 /tcp kind-control-plane 今回はマスターノードだけが構築されたので、シング ルノー ド クラスタ が構築されました。 (1つのノードだけなのでシングル クラスタ 、そのままですね) kindはコンテナをノードとして扱うツールですので、 docker コマンドでもノードの確認が可能です。 一旦、 k8s クラスタ をお掃除します。 $ kind delete cluster マルチノード クラスタ 作成 マスターノードだけのシング ルノー ド クラスタ が構築できたので、次はワーカーノードもあるマルチノード クラスタ を構築しましょう。 (複数のノードがあるからマルチノード、単純ですね) ドキュメントを参照するとymlファイルを使って構築できそうです。 以下の内容でymlファイルを作成し、 kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker - role: worker kind コマンドにて先程のymlファイルを指定し、 k8s クラスタ を構築します。 $ kind create cluster --config cluster.yml Creating cluster " kind " ... ... Set kubectl context to " kind-kind " $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME kind-control-plane Ready control-plane 34s v1. 24 . 0 172 . 24 . 0 . 4 < none > Ubuntu 21 . 10 5 . 10 .104-linuxkit containerd:// 1 . 6 . 4 kind-worker Ready < none > 11s v1. 24 . 0 172 . 24 . 0 . 3 < none > Ubuntu 21 . 10 5 . 10 .104-linuxkit containerd:// 1 . 6 . 4 kind-worker2 Ready < none > 11s v1. 24 . 0 172 . 24 . 0 . 2 < none > Ubuntu 21 . 10 5 . 10 .104-linuxkit containerd:// 1 . 6 . 4 $ docker container ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b101e316a8ff kindest/node:v1. 24 . 0 " /usr/local/bin/entr… " About a minute ago Up 55 seconds 127 . 0 . 0 .1:54512- > 6443 /tcp kind-control-plane 7e18515677be kindest/node:v1. 24 . 0 " /usr/local/bin/entr… " About a minute ago Up 55 seconds kind-worker2 913b69d58e62 kindest/node:v1. 24 . 0 " /usr/local/bin/entr… " About a minute ago Up 55 seconds kind-worker kubectl コマンド・ docker コマンド、それぞれでマスターノード1つとワーカーノード2つが作成されていることが確認できました。 ( Ubuntu が動いているみたいですね) アプリケーションをデプロイしてみる アプリケーションの実行環境であるワーカーノードができたので、実際にアプリケーションをワーカーノード上で動かしてみましょう。 k8s クラスタ 上のワーカーノードにアプリケーションをデプロイするには、Podを作成してデプロイします。 Podとは、 k8s オブジェクトモデルであり、実行できるアプリケーションの単位で、作成またはデプロイする最小かつ最も単純な単位になります。 今回は理解を単純にするために、1Pod1コンテナでPodを作成します。 では、Podを作成してデプロイするため、Podをymlで定義してみましょう。 apiVersion: v1 kind: Pod metadata: name: hoge-pod labels: component: hoge-nginx spec: containers: - name: nginx image: nginx:latest spec にて何のDockerイメージを取得するのか、定義しています。 (今回はnginxのlatest) Podをデプロイしてみましょう。 $ kubectl apply -f hoge-pod.yml hoge-pod created $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hoge-pod 1 / 1 Running 0 13s 10 . 244 . 1 . 5 kind-worker < none > < none > ステータスがRunnningとなっていれば、正常に作成されアプリケーションが稼働している状態です。 もしRunningになっていない場合は、以下コマンドで詳細が確認できます。 $ kubectl describe pods hoge-pod ... Events にエラー内容が記載されているので、そこを確認しましょう。 次に問題なくnginxが動いているのか、Podに入って確認します。 $ kubectl exec -it hoge-pod -- bash root@hoge-pod:/# curl -v localhost:80 HTTP/ 1 . 1 200 OK ... localhost:80 に curl すると、nginxのWelcomeページが返却されます。 なぜわざわざPodに入って確認したのかというと、Podは k8s クラスタ の内部に閉じているためです。 外部に公開する方法については、後項で紹介いたします。 一旦、 k8s クラスタ のPodをお掃除します。 $ kubectl delete pod hoge-pod アプリケーションをスケールする 前項では手動でPodをデプロイしましたが、同じ状態のPodを1つ2つと増やすにはどうしたら良いのでしょうか？ k8s には、ReplicaSetとDeploymentという機能があります。 ReplicaSetは、設定したレプリカ数分のPodを利用可能な状態で維持してくれる機能になります。 Deploymentは、ReplicaSetの上位レベルの概念でPodのローリングアップデート機能を提供しています。 Podをスケールするために、Deplymentをymlで定義してみましょう。 apiVersion: apps/v1 kind: Deployment metadata: name: hoge-deployment labels: component: hoge-nginx spec: replicas: 3 selector: matchLabels: component: hoge-nginx template: metadata: labels: component: hoge-nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 replicas でPodの数、 selector で管理するPodのラベルを定義しています。 なお、Podのラベルは templace.metadata.labels に定義されているものになります。 template で作成するPodを定義しています。 Deploymentを適用してみましょう。 $ kubectl apply -f hoge-deployment.yml deployment.apps/hoge-deployment created $ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE hoge-deployment 3 / 3 3 3 37s $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hoge-deployment-664bf7b75-2zvfm 1 / 1 Running 0 7s 10 . 244 . 2 . 7 kind-worker2 < none > < none > hoge-deployment-664bf7b75-4fdw8 1 / 1 Running 0 7s 10 . 244 . 1 . 6 kind-worker < none > < none > hoge-deployment-664bf7b75-5k8s7 1 / 1 Running 0 7s 10 . 244 . 1 . 7 kind-worker < none > < none > Deploymentを適用すると、 replicas で指定された数のPodが作成されます。 試しにPodを1つ削除してみましょう。 $ kubectl delete pods hoge-deployment-664bf7b75-2zvfm pod " hoge-deployment-664bf7b75-2zvfm " deleted $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hoge-deployment-664bf7b75-4fdw8 1 / 1 Running 0 88s 10 . 244 . 1 . 6 kind-worker < none > < none > hoge-deployment-664bf7b75-5k8s7 1 / 1 Running 0 88s 10 . 244 . 1 . 7 kind-worker < none > < none > hoge-deployment-664bf7b75-vgb9k 1 / 1 Running 0 19s 10 . 244 . 2 . 8 kind-worker2 < none > < none > 1つ削除しましたが、Podを確認すると3つになっています。 AGE から見るに1番下のPodが新規に作成されたようです。便利ですね。 これでアプリケーションのスケールアウト・スケールインが可能となりました。 一旦、 k8s クラスタ をお掃除します。 $ kind delete cluster アプリケーションに外部から接続する(NodePort Service) 前項にてDeploymentでPodを複数作成しましたが、 IPアドレス が動的なことにお気づきでしょうか？。 # 1Pod削除前 $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hoge-deployment-664bf7b75-2zvfm 1 / 1 Running 0 7s 10 . 244 . 2 . 7 kind-worker2 < none > < none > hoge-deployment-664bf7b75-4fdw8 1 / 1 Running 0 7s 10 . 244 . 1 . 6 kind-worker < none > < none > hoge-deployment-664bf7b75-5k8s7 1 / 1 Running 0 7s 10 . 244 . 1 . 7 kind-worker < none > < none > # 1Pod削除後 $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hoge-deployment-664bf7b75-4fdw8 1 / 1 Running 0 88s 10 . 244 . 1 . 6 kind-worker < none > < none > hoge-deployment-664bf7b75-5k8s7 1 / 1 Running 0 88s 10 . 244 . 1 . 7 kind-worker < none > < none > hoge-deployment-664bf7b75-vgb9k 1 / 1 Running 0 19s 10 . 244 . 2 . 8 kind-worker2 < none > < none > 新しく作成されたPodの IPアドレス が、削除されたPodとは異なる IPアドレス が設定されています。 ( 10.244.2.7 から 10.244.2.8 に) k8s クラスタ は動的な環境となっています。 例えば IPアドレス 指定でPodにアクセスしていると、バージョンアップ等でPodが再作成された場合にアクセスできなくなってしまいます。 また、 IPアドレス 指定でのアクセスですと、1つのPodにしかアクセスされず負荷分散ができていません。 そこで登場するのがServiceになります。 Serviceは、Podの集合で実行されているアプリケーションをネットワークサービスとして公開してくれる機能です。 特定のラベルを持ったPodのどれかにアクセスできるようエンドポイントを提供してくれます。 Podにアクセスできるようにするために、Serviceをymlで定義してみましょう。 apiVersion: v1 kind: Service metadata: name: hoge-service spec: type: NodePort selector: component: hoge-nginx ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30080 今回は NodePort タイプのServiceを定義しています。 NodePort タイプにすることで、ノードの対象ポートへの通信をServiceへ転送するようになります。 selector でPodのラベルを指定しPodの集合体を形成し、 port はServiceのポートになります。 また、 targetPort はPodが待ち受けているポート、 nodePort はノードからSerivceへ通信を転送するポートになります。 Serviceにアクセスできるように k8s クラスタ を構築し直します。 新しい k8s クラスタ をymlで定義します。 kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker extraPortMappings: - containerPort: 30080 hostPort: 30080 protocol: TCP ワーカーノードのポート:30080と自端末のポート:30080を紐付けています。 k8s クラスタ を作成しましょう。 $ kind create cluster --config cluster.yml ... $ docker container ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e8c8938d96a7 kindest/node:v1. 24 . 0 " /usr/local/bin/entr… " 2 minutes ago Up 2 minutes 0 . 0 . 0 .0:30080- > 30080 /tcp kind-worker c901092d5858 kindest/node:v1. 24 . 0 " /usr/local/bin/entr… " 2 minutes ago Up 2 minutes 127 . 0 . 0 .1:58099- > 6443 /tcp kind-control-plane ワーカーノードのポート:30080と自端末のポート:30080が紐付けられています。 k8s クラスタ ができたので、DeploymentとServiceを適用しましょう。 $ kubectl apply -f hoge-deployment.yml deployment.apps/hoge-deployment created $ kubectl apply -f hoge-service.yml service/hoge-service created $ kubectl get pods,deployments,services -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/hoge-deployment-664bf7b75-scclb 1 / 1 Running 0 6m47s 10 . 244 . 1 . 3 kind-worker < none > < none > pod/hoge-deployment-664bf7b75-x4gzc 1 / 1 Running 0 6m47s 10 . 244 . 1 . 2 kind-worker < none > < none > pod/hoge-deployment-664bf7b75-xdm4j 1 / 1 Running 0 6m47s 10 . 244 . 1 . 4 kind-worker < none > < none > NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR deployment.apps/hoge-deployment 3 / 3 3 3 6m47s nginx nginx:latest component =hoge-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT ( S ) AGE SELECTOR service/hoge-service NodePort 10 . 96 . 122 . 115 < none > 80:30080/TCP 6s component =hoge-nginx service/kubernetes ClusterIP 10 . 96 . 0 . 1 < none > 443 /TCP 11m < none > 全て正常に動いていることが確認できたら、自端末から curl もしくはブラウザで localhost:30080 にアクセスしてみましょう。 $ curl -i localhost:30080 HTTP/ 1 . 1 200 OK ... Serviceの selector に誤りがなければ、nginxのWelcomeページが返却されます。 これで、 k8s クラスタ 内のアプリケーションにアクセスできるようになりました。 一旦、 k8s クラスタ をお掃除します。 $ kind delete cluster アプリケーションに外部から接続する( Ingress ) マイクロサービス化に伴い、URLのパスによって異なるアプリケーションを参照したいとなった場合はどうすればよいでしょうか？ Ingress が解決してくれます。 Ingress とは、 k8s クラスタ 内のServiceに対する外部からのアクセスを管理する API オブジェクトです。 hoge.example.com/hoge へのリク エス トは、 hoge アプリがデプロイされているPod群の hoge-service へ hoge.example.com/fuga へのリク エス トは、 fuga アプリがデプロイされているPod群の fuga-service へ Ingress がルーティングしてくれます。 ルーティングするために、 Ingress をymlで定義してみましょう。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: hoge-fuga-ingress spec: ingressClassName: nginx rules: - http: paths: - pathType: Prefix path: "/" backend: service: name: nginx-service port: number: 80 - pathType: Prefix path: "/hoge" backend: service: name: hoge-service port: number: 80 - pathType: Prefix path: "/fuga" backend: service: name: fuga-service port: number: 80 localhost にアクセスすると、 nginx-service へ localhost/hoge にアクセスすると、 hoge-service へ localhost/fuga にアクセスすると、 fuga-service へ それぞれルーティングする定義となります。 3アプリケーションのDeploymentの定義は以下になります。 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: component: nginx spec: replicas: 3 selector: matchLabels: component: nginx template: metadata: labels: component: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: hoge-deployment labels: component: hoge-echo spec: replicas: 3 selector: matchLabels: component: hoge-echo template: metadata: labels: component: hoge-echo spec: containers: - name: nginx image: hashicorp/http-echo:latest args: - "-text=hoge" ports: - containerPort: 5678 --- apiVersion: apps/v1 kind: Deployment metadata: name: fuga-deployment labels: component: fuga-echo spec: replicas: 3 selector: matchLabels: component: fuga-echo template: metadata: labels: component: fuga-echo spec: containers: - name: nginx image: hashicorp/http-echo:latest args: - "-text=fuga" ports: - containerPort: 5678 3アプリケーションのServiceの定義は、以下になります。 apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: component: nginx ports: - protocol: TCP port: 80 targetPort: 80 --- apiVersion: v1 kind: Service metadata: name: hoge-service spec: selector: component: hoge-echo ports: - protocol: TCP port: 80 targetPort: 5678 --- apiVersion: v1 kind: Service metadata: name: fuga-service spec: selector: component: fuga-echo ports: - protocol: TCP port: 80 targetPort: 5678 kindで Ingress を利用するにあたって、 k8s クラスタ を定義したymlを修正します。 kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane kubeadmConfigPatches: - | kind: InitConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "ingress-ready=true" extraPortMappings: - containerPort: 80 hostPort: 80 protocol: TCP 上記定義はkindの ドキュメント に記載されているものを利用しています。 k8s クラスタ を構築し、Deployment・Service・ Ingress を適用しましょう。 $ kind create cluster --config cluster.yml Creating cluster "kind" ... Set kubectl context to "kind-kind" $ kubectl apply -f hoge-fuga-deployment.yml deployment.apps/nginx-deployment created deployment.apps/hoge-deployment created deployment.apps/fuga-deployment created $ kubectl apply -f service/hoge-fuga-service.yml service/nginx-service created service/hoge-service created service/fuga-service created $ kubectl apply -f ingress/hoge-fuga-ingress.yml ingress.networking.k8s.io/hoge-fuga-ingress created $ kubectl get pods,deployments,services,ingress -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/fuga-deployment-65bf9f9c78-kngtk 1/1 Running 0 104s 10.244.0.9 kind-control-plane <none> <none> pod/fuga-deployment-65bf9f9c78-nmv2g 1/1 Running 0 104s 10.244.0.12 kind-control-plane <none> <none> pod/fuga-deployment-65bf9f9c78-wmqwr 1/1 Running 0 104s 10.244.0.11 kind-control-plane <none> <none> pod/hoge-deployment-7df96b5f86-84kpt 1/1 Running 0 104s 10.244.0.10 kind-control-plane <none> <none> pod/hoge-deployment-7df96b5f86-8l5fr 1/1 Running 0 104s 10.244.0.13 kind-control-plane <none> <none> pod/hoge-deployment-7df96b5f86-t9dpd 1/1 Running 0 104s 10.244.0.6 kind-control-plane <none> <none> pod/nginx-deployment-f78754554-7hkmw 1/1 Running 0 104s 10.244.0.7 kind-control-plane <none> <none> pod/nginx-deployment-f78754554-dmnc4 1/1 Running 0 104s 10.244.0.5 kind-control-plane <none> <none> pod/nginx-deployment-f78754554-rw2lb 1/1 Running 0 104s 10.244.0.8 kind-control-plane <none> <none> NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR deployment.apps/fuga-deployment 3/3 3 3 104s nginx hashicorp/http-echo:latest component=fuga-echo deployment.apps/hoge-deployment 3/3 3 3 104s nginx hashicorp/http-echo:latest component=hoge-echo deployment.apps/nginx-deployment 3/3 3 3 104s nginx nginx:latest component=nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service/fuga-service ClusterIP 10.96.94.98 <none> 80/TCP 72s component=fuga-echo service/hoge-service ClusterIP 10.96.24.225 <none> 80/TCP 72s component=hoge-echo service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4m58s <none> service/nginx-service ClusterIP 10.96.128.45 <none> 80/TCP 72s component=nginx NAME CLASS HOSTS ADDRESS PORTS AGE ingress.networking.k8s.io/hoge-fuga-ingress nginx * 80 41s Ingress は作成するのみでは利用できず、IngressControllerが必要となります。 今回は NGINX IngressController を利用します。 kindの ドキュメント で紹介されている手順で導入します。 $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml ... $ kubectl wait --namespace ingress-nginx \ --for=condition=ready pod \ --selector=app.kubernetes.io/component=controller \ --timeout=90s pod/ingress-nginx-controller-86b6d5756c-s2sn4 condition met $ kubectl get pods -o wide -n ingress-nginx NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ingress-nginx-admission-create-jjqjf 0 / 1 Completed 0 2m6s 10 . 244 . 0 . 15 kind-control-plane < none > < none > ingress-nginx-admission-patch-9wzgg 0 / 1 Completed 0 2m6s 10 . 244 . 0 . 14 kind-control-plane < none > < none > ingress-nginx-controller-86b6d5756c-s2sn4 1 / 1 Running 0 2m6s 10 . 244 . 0 . 16 kind-control-plane < none > < none > ingress-nginx-controller がRunningとなっていれば、正常に稼働しています。 全て正常に動いていることが確認できたら、自端末から curl もしくはブラウザで localhost ・ localhost/hoge ・ localhost/fuga にアクセスしてみましょう。 $ curl -i localhost ... < h 1> Welcome to nginx! < /h 1> ... $ curl -i localhost/hoge ... hoge $ curl -i localhost/fuga ... fuga URLのパスによって、異なるアプリケーションが呼ばれていることが確認できました。 ここまでやると何となくですが、 k8s の雰囲気が掴めたかなと思います。 アカウントや認証周りについてはまだまだ勉強中なので、今回は割愛します。 一旦、 k8s クラスタ をお掃除します。 $ kind delete cluster ArgoWorkflowsの導入 ArgoWorkflowsの導入です。 ArgoWorkflows のクイックスタートを参照すると、ポート フォワ ードでの手順となっています。 せっかく Ingress が使えるようになったので、今回は Ingress 経由でArgoWorkflowsを覗けるようにしてみましょう。 まずは、 k8s クラスタ ーの構築です。 Ingress を利用するので前項のymlを利用します。 $ kind create cluster --config cluster.yml Creating cluster " kind " ... Set kubectl context to " kind-kind " k8s クラスタ が構築できたので、ArgoWorkflowsを導入します。 まずは、ArgoWorkflows用にNamespaceを作成します。 Namespaceは、 k8s クラスタ ーリソースを分割する方法であり、プロジェクト毎に パーティション を切るようなイメージです。 $ kubectl create namespace argo $ kubectl get namespace NAME STATUS AGE argo Active 150m default Active 178m ingress-nginx Active 147m kube-node-lease Active 179m kube-public Active 179m kube-system Active 179m local-path-storage Active 178m Namepspaceを明示しなかった場合は、基本的に default が利用されます。 ArgoWorkflowsのインストールですが、 k8s のControllerとして動かしたいので、リリースノート( v3.3.8 )から以下コマンドでインストールします。 $ kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3. 3 . 8 /install.yaml ArgoWorkflowsの Ingress を、ymlで定義してみましょう。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argo-server-ingress namespace: argo spec: ingressClassName: nginx rules: - http: paths: - pathType: Prefix path: / backend: service: name: argo-server port: number: 2746 公式ドキュメント を参照すると色々書いてありますが、今回は簡単な定義にしています。 Ingress を適用しましょう。 $ kubectl apply -f argo-ingress.yml ingress.networking.k8s.io/argo-server-ingress created Ingress を定義しただけではまだ利用できないので、前項でも利用したNGINX IngressControllerを導入します。 $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml ... $ kubectl wait --namespace ingress-nginx \ --for=condition=ready pod \ --selector=app.kubernetes.io/component=controller \ --timeout=90s pod/ingress-nginx-controller-86b6d5756c-s2sn4 condition met ArgoWorkflowsの導入はできたのですが、ArgoWorkflowsは HTTPS で待ち受ける設定となっています。 今回は Ingress 配下にArgoWorkflowsを構築しているので、HTTPで待ち受ける設定に変更します。 $ kubectl edit deployment/argo-server --namespace=argo # 1. vim(デフォルトエディタ)が起動されるので、 # template.spec.containers.argsに2項目(--secure, --auth-mode)を追加 spec: containers: - args: - server - --secure=false # HTTPでの通信に変更 - --auth-mode=server # ArgoWorkflowsを動かしたいだけなので認証なしモード # 2. HTTPSと定義されている部分をHTTPで一括置換(vim) : %s/HTTPS/HTTP/g # 3. 保存 : wq deployment.apps/argo-server edited 変更を保存すると変更内容が反映されます。 それではブラウザでアクセスしてみましょう。 open http://localhost ArgoWorkflowsの画面が表示されれば成功です。 試しにワークフローを動かしてみましょう。 まずは、WorkflowTemplateの作成です。 左メニューの Workflow Template -> CREATE NEW WORKFLOW TEMPLATE -> CREATE これでテンプレのワークフローが作成されます。 作成されたワークフローの SUBMIT を押下し、パラメータ設定画面の SUBMIT を押下します。 ワークフロー実行画面に遷移し、少し待つと成功します。 まとめ 以上、kindを使って k8s の雰囲気を掴みながら、ArgoWorkflowsの構築までできました。 k8s 初心者からほんの少しわかるくらいにはなれたのではないでしょうか。 本記事が k8s 理解の一助となれたら幸いです。 最後までお読みいただきありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

まえがき WAFについて（概要） WAFとFirewall（ファイアウォール）とは異なる点 WAFとIPS/IDSとは異なる点 WAFの効果 実害がある場合（攻撃を受けた状態） 実害はない場合（脆弱性が発見された場合など） WAFで対応可能な攻撃の種類 WAFの種類 クラウド型WAFを触ってみた 思わぬ落とし穴 ■良かったこと ■悪かったこと まとめ まえがき お初の方は初めまして。 そうでない方はこんにちは。 ラク スでインフラを担当していますru369と申します。 今回は、WAFについて記事にまとめましたのでよろしくお願いします。 WAFについて（概要） WAFとは・・・Web Application Firewall の略称で通称：ワフと呼びます。 Webアプリケーションの 脆弱性 を突いた攻撃への対策のひとつであり、Webサーバの前面に配置して通信を解析し、Webサイトを保護するセキュリティ対策です。 動作としては一般的な ファイアウォール と似ていますが、異なるところはデータの中身をアプリケーション層レベルで解析できるのが特徴です。 ➡ ECサイト などでのオンラインショッピングやゲームといった個人情報やクレジットカード情報など、ユーザーからの入力を受け付けるようなタイプのWebサイトを不正な攻撃から守ってくれます！ WAFと似たセキュリティ対策として、 Firewall 、IPS/IDSがありますが、それぞれ用途（防御の箇所）が異なります。 WAFとの違い WAFと Firewall （ ファイアウォール ）とは異なる点 Firewall は ネットワーク層 レベルでのセキュリティ対策です。 送信元と 送信先 の情報（ IPアドレス やポート番号など）を元に内部ネットワークへのアクセスを制限します。 ポートスキャンなどの外部公開が不要なサービスを狙った通信は制限できますが、 通信の中身までは検査しません。 ➡正常な通信（パケット）を装った攻撃を区別できず対処できません。 WAFとIPS/IDSとは異なる点 IPS（Intrusion Prevention System） 不正侵入防止システムと呼ばれプラットフォームレベルでのセキュリティ対策です。 IDS（Intrusion Detection System） 不正侵入検知システムと呼ばれ、異常な通信を検知する為に使われます。 ➡簡単に言えば、異常な通信を検知するのはIDS、それをさらに防御まで行うのがIPSというイメージです。 IPS/IDSは、種類により様々ですが、 ファイアウォール よりも内側、反対の外側、 DMZ 上といった設置パターンがあります。 Firewall よりも内側に設置する場合は ファイアウォール を補完する形で防御性能をアップさせます。 一方で外側に設置する場合は、ログを取得して攻撃を把握、分析します。 DMZ 上では、 Firewall をすり抜けてきた攻撃を検出・防御します。 このように使い方によりけりではありますが、IPS/IDSは、OSや ミドルウェア の 脆弱性 を突いた攻撃や、ファイル共有サービスへの攻撃など、さまざまな種類の攻撃を検査・防御します。 しかしながら、Webアプリケーションへの攻撃は多種多様に増えているため、IPSでは攻撃を防ぎきれないことがあります。 また、解析のためにネットワークの性能劣化や遅延が起きてネットワークが使えなくなることがあります。 WAFの効果 WAFを導入しておくと、どのようなことに役に立つのかご紹介します。 情報流出等の セキュリティインシデント が発生すると、以下のようなことに遭遇し得ます。 企業の社会的信用の失墜 Webサイトの長期的閉鎖による機会損失 機会損失により売り上げが下がり直接的／関節的な対策のコストが必要 一方でWAFによる対策をしていると、以下のような事態に遭遇した際に即対応することができます。 実害がある場合（攻撃を受けた状態） 攻撃を受けたWebサイトが実害を受けた場合、元の状態に戻すまでに時間がかかってしまう すぐに防御できないため、対策できるまで被害が拡大してしまう恐れ 攻撃を受ける前と同じ状態でサービスを暫定的であっても再開できない 実害はない場合（ 脆弱性 が発見された場合など） Webアプリケーションに 脆弱性 が発見されてもすぐにアプリケーションの改修を行うことは難しく、暫定的な緊急措置がとれない Webアプリケーションが複数ある場合は、それぞれに対応が必要なため、すべてに対応するまで時間がかかる WAFで対応可能な攻撃の種類 基本的にWAFは OWASP Top 10（OWASP:The Open Web Application Security Project）に準拠していると思います。 導入製品によって異なる部分もあると思いますが、例として以下のような攻撃に対してWAFは効力を発揮します。 XSS （ クロスサイトスクリプティング ）攻撃 OSコマンドインジェクション ディレクト リ・トラバーサル（ パストラバーサル ） パスワードリスト攻撃 ブルートフォース アタック DoS / DDoS攻撃 バッファオーバーフロー WAFの種類 主に以下の3種類があります。 OSS のWAFもありますので合わせて紹介です。 アプライアンス 型WAF（ ゲートウェイ 型WAF） WAF専用機器を ゲートウェイ に設置して導入します。 既存のネットワークに直列で接続する「インライン型」や、スイッチなどの ミラーリング ポートに接続する「ミラー型」などがあります。 導入にはネットワーク構成を考慮する必要がありますが、保護対象のWebサーバには負荷がかかりません。 クラウド 型WAF（サービス型WAF） ネットワーク設定を一部変更し、インターネットを経由して クラウド サービスを受けることができます。 基本的に運用は クラウド サービス提供者が行うため、チューニングや 脆弱性 対応も自分で行う必要はありません。 また、機器購入等が不要なことから初期費用を抑えることができます。 ソフトウェア型WAF（ホスト型WAF） 保護対象となるWebサーバーにWAFのソフトウェアをインストールし、通信内容を検査します。 保護対象のサーバーに直接インストールするため、ネットワーク環境の構成や他のサーバーなどに影響を与えず導入することが出来ます。 オープンソース のWAF 無料で利用できる オープンソース のWAFもあります。 　・ModSecurity 　・NAXSI 　・WebKnight 余談ですが、「 OSS WAF」で調べてみるとModSecurityが突出している印象です。 クラウド 型WAFを触ってみた 過去にModSecurityを触ったことはありますが、最近 クラウド 側WAFに触る機会がありましたのでそのお話を少しできればと思います。 （なお、WAFそのものよりどちらかというとリバースプロキシサーバの話になります。） ここでの導入イメージは、1台のWebサーバ（ Apache ）の前段にWAF（リバースプロキシ（nginx））を導入する形です。 導入前の準備 WAFに転送先（実際のアクセス先）のWebサーバの IPアドレス を登録します。 細かいことでいうと SSH 接続や接続方法（HTTP(S)接続）の設定、チューニングなどが後の作業として控えていますが、最低限の導入準備はこれで終わりです。 ※Webサーバの前段にLoadbalancerサーバがあるような構成であれば、Loadbalancerの IPアドレス を登録することになると思います。 導入してみる WAFの導入は、Webサーバに設定している グローバルIPアドレス の DNS レコード（CNAMEレコードやAレコード）にWAFの IPアドレス を登録するのみです。 導入後 導入後はWAFを経由している分、経由していない場合と比較して、アクセスにかかる時間は数ミリ秒伸びました。 Webアクセスには基本的に影響はなく、WAFの検知テストを行ってもきっちり検知されブロックもされました。 思わぬ落とし穴 WAF自体とは少しずれますが、リバースプロキシサーバの運用経験がほとんどなかったことから嵌ってしまった落とし穴がありました。 良かったことと悪かったことに遭遇しました。 ■良かったこと これまでWebサーバが受け付けていたすべてのアクセスを前段のWAFが受けてくれる形になったことで、Webサーバの負荷が減少しました。 WAF側でキャッシュ機能を有効にしていたり、レスポンスの圧縮をしてくれること、クライアントごとの SSL / TLS リク エス トの暗号化と復号化を代わりにやってくれるためと考えられます。 ■悪かったこと ブラウザからWebアクセスをしていると、WAFにて502エラー、504エラーがランダムで発生していることが確認できました。 実際ブラウザ側では稀にエラー画面が表示されることがありました。 504エラー WAFとWebサーバとの タイムアウト 値の関係がWAF < Webサーバとなっていたことが原因でした。 WAF >= Webサーバに タイムアウト 値を直したところ激減（ほぼ0件）になりました。 502エラー 当初難航しました。 なぜなら特定のアクセスに起因するものではない上、WAF、Webサーバ双方のログから調査することができなかったためです。 （ググってもあまり情報がでてこなかったのも辛かったです） この問題を回避するには、WAFとWebサーバのKeepAliveTimeoutの値の関係をWAF < Webサーバにする必要がありました。 （KeepAliveとKeepAliveTimeoutの補足） KeepAliveは、一度 TCP の接続が行われると同じ接続内で複数のリク エス トのやり取りを行うための設定であり、KeepAliveTimeoutで設定した時間内にクライアントから次のリク エス トが送信されてこなくなると TCP 接続を切断します。 導入当初は、WAF > Webサーバの関係でKeepAliveTimeout値が設定されてしまっていました。 クライアント→WAF→Webサーバの流れでアクセスがありますが、 後続の WAF→Webサーバ間 のコネクションが クライアント→WAF間 よりも短い タイムアウト で切断 され、そのタイミングでクライアントから握ったままになっていたコネクションを利用しようとしたときにエラーになることがあるのだと思います。 ➡WAF < Webサーバの関係のことは Amazon のELB関係のページにも記載がありました。 （参考： https://aws.amazon.com/jp/premiumsupport/knowledge-center/apache-backend-elb/ ） WAF < Webサーバの適正なKeepAliveTimeout値は、2倍3倍以上の差にする必要がありますが一概には言えないので、チューニングしてエラーが発生しない分岐点を探っていく必要があります。 なお、KeepAliveTimeoutを0にするとエラーは発生しなくなりますが、 動作が驚くほど遅くなります のでお勧めしません。 （KeepAlive が0（=無効）になっていると、最初に TCP コネクションを確立したあと、リク エス トの送信及びレスポンスの送信が行われ、都度 TCP の接続がいったん切れます。複数のリク エス トを送る場合にはリク エス トの度に TCP の接続を確立する必要がでてきてしまうためと思われます。） まとめ 昨今のセキュリティ事故事情から様々なセキュリティ強化を求められると思います。 WAF導入の話が出てきた際に、（拙くて申し訳ないですが）本ブログが少しでもお役に立てれば幸いです。 ※参考にしたページ https://httpd.apache.org/docs/2.4/ja/mod/core.html#keepalivetimeout http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout https://kinsta.com/jp/blog/reverse-proxy/ https://aws.amazon.com/jp/premiumsupport/knowledge-center/apache-backend-elb/ https://it-trend.jp/waf/article/poodle https://www.digicert.com/jp/waf/waf-ips-ids https://it-trend.jp/ids-ips/article/difference https://cweb.canon.jp/it-sec/solution/siteguard/waf/ https://www.jbsvc.co.jp/useful/security/what-is-waf.html エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

技術広報の yayawowo です。 皆様、 SQL を日頃お使いでしょうか？ 今回は、 「データを追加」する際に欠かせないINSERT文の使い方と、おすすめの書籍をご紹介 します。 INSERT文の使い方を習得いただくため、お手元で実行可能な SQL 文付きで解説します。 是非、実践しながら習得ください！ ※本説明では、 PostgreSQL 9.6を利用します。 テーブルの準備 INSERT文をマスターしよう 基本的な使い方 複数レコードを同時INSERT 別テーブルにINSERT おすすめの書籍 INSERT まとめ ◆ 【 SQL 入門】 PostgreSQL 関連記事 ・ 【SQL入門】UPDATE まとめ ・ 【SQL入門】DISTINCT 使い方 ・ RDBMSとDBMSについて【初心者向け】 ・ SQLの基本【まとめ】 ・ 【RDBMS】PostgreSQLインストール・コマンド入門編 テーブルの準備 まず、INSERT文の解説に入る前に今回使うテーブルを作成します。 テーブルの列定義とCREATE文は以下の通りです。 ◆ 列定義 列名 データ型 PK animal _no integer ○ animal_name text animal_breed text skill _no integer skill_name text ◆ SQL 文 --テーブル作成SQL文 CREATE TABLE sample_animal ( animal_no integer primary key, animal_name text, animal_breed text, animal_sex text, skill_no integer , skill_name text ); では、テーブルが完成しましたのでINSERT文の説明に入ります。 INSERT文をマスターしよう 基本的な使い方 INSERT文の基本的な使い方として、テーブルにデータを登録する方法をご説明します。 まず初めに、列名を指定するパターンです。 ＜ 書式：列名指定有パターン ＞ INSERT INTO テーブル名 (列名1, 列名2,....) VALUES (値1, 値2, ...) ; テーブル名：データを登録したいテーブル名を記載する 列名：値を追加したい列名を記載する 値　：追加したい値を記載する では、INSERT文を書いてみましょう！ ◆ SQL 文 --SQL文：INSERTの基本(列名指定有） INSERT INTO sample_animal (animal_no, animal_name, animal_breed, animal_sex, skill_no, skill_name) VALUES ( 1 , ' 犬 ' , ' 柴犬 ' , ' 女 ' , 1 , null ); INSERT INTO sample_animal (animal_no, animal_name, animal_breed, animal_sex, skill_no, skill_name) VALUES ( 2 , ' 犬 ' , ' 柴犬 ' , ' 男 ' , 2 , null ); INSERT INTO sample_animal (animal_no, animal_name, animal_breed, animal_sex, skill_no, skill_name) VALUES ( 3 , ' 犬 ' , ' チワワ ' , ' 男 ' , 1 , null ); ◆実行結果 animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 (null) 2 犬 柴犬 男 2 (null) 3 犬 チワワ 男 1 (null) なお、上記 SQL 文では列名一つ一つ指定しましたが、省略することもできます。 列名指定をしない場合のINSERT文は、以下の通りです。 ＜ 書式：列名指定無パターン ＞ INSERT INTO テーブル名 VALUES (値1, 値2, ...) ; ※注意点 列名指定をしない場合の「値」は、列名順通りに正しく指定するよう、注意ください！ ◆ SQL 文 --SQL文：INSERTの基本(列名指定無） INSERT INTO sample_animal VALUES ( 1 , ' 犬 ' , ' 柴犬 ' , ' 女 ' , 1 , null ); INSERT INTO sample_animal VALUES ( 2 , ' 犬 ' , ' 柴犬 ' , ' 男 ' , 2 , null ); INSERT INTO sample_animal VALUES ( 3 , ' 犬 ' , ' チワワ ' , ' 男 ' , 1 , null ); 実行結果は列名を指定した結果と変わりません。 列名を指定しない場合はとてもシンプル且つ、便利に見えますが、想定していないトラブルが発生するリスクもあります。 列名指定をしないINSERT文を使う際は、ご注意いただきながらご利用ください。 複数レコードを同時INSERT 続いて、複数レコードを1つのINSERT文を使い同時に追加する場合を説明します。 前述したINSERTの基本をご理解いただけていれば、とても簡単な方法です。 ＜ 書式 ＞ INSERT INTO テーブル名 VALUES (値1-1, 値1-2, 値1-3), (値2-1, 値2-2, 値3-3) ... ; では、実際に値を入れてみてみましょう。 ◆ SQL 文 --SQL文：複数レコード同時INSERT INSERT INTO sample_animal VALUES ( 1 , ' 犬 ' , ' 柴犬 ' , ' 女 ' , 1 , null ), ( 2 , ' 犬 ' , ' 柴犬 ' , ' 男 ' , 2 , null ), ( 3 , ' 犬 ' , ' チワワ ' , ' 男 ' , 1 , null ); ◆実行結果 animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 (null) 2 犬 柴犬 男 2 (null) 3 犬 チワワ 男 1 (null) VALUESの後に同時INSERTしたい値を指定しているのが、お分かりいただけるのではないでしょうか？ INSERT文を1つずつ書くよりも効率的ですね。 別テーブルにINSERT 別テーブルに問い合わせる処理である「副問合せ（サブクエリ）」を使った、INSERT文についてご説明します。 今回利用するテーブルの準備を先にしましょう。 初めに今回SELECT文で呼び出す、sample_animalテーブルのデータを以下の内容でUPDATEします。 skill _no が1の場合：走る skill _no が2の場合：飛ぶ ◆ SQL 文 --SQL文：sample_animalテーブルをUPDATE UPDATE sample_animal SET skill_name = ' 走る ' WHERE skill_no = 1 ; UPDATE sample_animal SET skill_name = ' 飛ぶ ' WHERE skill_no = 2 ; ◆実行結果 animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 走る 2 犬 柴犬 男 2 飛ぶ 3 犬 チワワ 男 1 走る 実行結果のようになりましたか？ では、次に今回SELECTで呼び出した値を書き出す、sample_skill テーブルをCREATEしてみましょう。 ◆ 列定義 列名 データ型 PK skill _no integer ○ skill_name text ◆ SQL 文 --テーブル作成SQL文 CREATE TABLE sample_skill ( skill_no integer primary key, skill_name text ); ここまで来ましたら準備完了です。 では、sample_animalテーブルからSELECTで呼び出した値を別テーブルである、sample_skill テーブルにINSERTしてみます。 利用する書式は以下の通りです。 ＜ 書式 ＞ INSERT INTO テーブル名1 (列名1, 列名2, .... ) 　 SELECT テーブル名2.列名 FROM テーブル名2 WHERE 条件; SQL 文をたたいてみましょう！ ◆ SQL 文 --SQL文：別テーブルにINSERT INSERT INTO sample_skill SELECT sample_animal.skill_no, sample_animal.skill_name FROM sample_animal WHERE animal_no IN ( 1 , 2 ); ◆実行結果 animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 走る 2 犬 柴犬 男 2 飛ぶ 3 犬 チワワ 男 1 走る skill _no skill_name 　 　 　👇 skill _no skill_name 1 走る 2 飛ぶ 上記実行結果の通り、スキルだけを抽出することができました。 INSERT文の使い方の説明は以上となります。 もし、INSERT文だけでなく、CREATE文/ SELECT文/UPDATE文を何も見ずに書ける人は、次ステップである SQL でのパフォーマンスチューニングに挑戦するのもおすすめです！ おすすめの書籍 これから SQL を学びたい方に、おすすめの3冊はこちら！ ◆ スッキリわかる SQL 入門 第2版 ◆ イラストで理解　 SQL 　はじめて入門 ◆ SQL 第2版 ゼロからはじめるデータベース操作 (プログラミング学習シリーズ) DB設計やパフォーマンスチューニングを学びたい方に、おすすめの4冊はこちら！ ◆ SQL 実践入門──高速でわかりやすいクエリの書き方 ◆ SQL パフォーマンス詳解 ◆ SQL アンチパターン ◆ 達人に学ぶDB設計 徹底指南書 INSERT まとめ いかがでしたでしょうか？ 今回は、 SQL 入門としまして『INSERT まとめ』をご紹介させていただきました。 実際にお手元で SQL を動かすことで、より理解を深めることができたのではないでしょうか。 改めまして、本記事がINSERT文を学ぶ方にとって、少しでもお役たてれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

Gitを使って開発する際、最新の ソースコード を取得する場面は多分にあると思います。 本投稿では、 git pull コマンドの基本的な使い方〜主要なオプションの紹介 をすると共に、よく混同されがちな、 fetch と merge との違い についてもまとめさせていただきます。 Gitを使い始めたばかりの方から、 git pull について学び直したいという方まで、開発の際に参考にしていただければ幸いです。 弊社ブログのGitに関わる関連記事もぜひご一読ください！ 【超入門】初心者のためのGitとGitHubの使い方 【Git入門】git stashで作業を便利に退避する 【Git入門】git commitを取り消したい、元に戻す方法まとめ 【Git入門】git cloneで既存リポジトリをクローンしよう！ 目次 目次 git pullとは？ git pullの基本的な使い方 git pullとfetchとmergeの関係性 git pullのオプション紹介 pull時のメッセージを非表示にする ダウンロードコンテンツの詳細を表示する mergeをrebaseに変更する merge時のコミットを実行しない まとめ 　 git pull とは？ git pull とは、 リモー トリポジ トリから最新の状態をローカル リポジトリ に反映するコマンド のことです。 状態と記載した通り、反映される対象は ソースコード 等のファイルだけではなく、履歴やログも含まれます。 複数人で システム開発 をする場合、各々の環境から作業を行うため、他の開発者が実装した内容をローカル リポジトリ に取り込む必要があります。 「作業の初めに必ず git pull を実行する」といったルールを作ることで、リモー トリポジ トリと差分のない状態で開発に着手することができます。 git pull の基本的な使い方 $ git pull 上記コマンドにより、リモー トリポジ トリの状態をローカル リポジトリ に反映することができます。 このように引数無しでコマンドを実行した場合は、作業中のブランチと関連付けられているリモー トリポジ トリのブランチを対象に pull が実行されます。 この関連付けられているブランチのことを アップストリーム（upstream）ブランチ と呼びます。 アップストリームブランチは以下コマンドで確認できます。 $ git branch -vv 実行結果は下記のような出力となります。 $ git branch -vv * main XXXXXXXX(コミット番号) [origin/main] Merge branch 'feature/hogehoge' into 'main' 上記の例ですと、ローカルの main ブランチのアップストリームブランチが origin/main であることが分かります。 また、デフォルトのアップストリーム以外のブランチを指定したい場合は git pull に引数をつけて実行します。 $ git pull <remote> <branch> 実行例は下記のようになります。 $ git pull origin feature/hogehoge アップストリームブランチを明示的に設定する場合は、以下コマンドを実行します。 $ git branch --set-upstream-to=<remote>/<branch> [ローカルブランチ名] git pull と fetch と merge の関係性 git fetch は、 git pull と同じくリモー トリポジ トリから最新の状態をローカルに反映するコマンドなのですが、反映先がアップストリームブランチとなります。 また、 git merge はアップストリームブランチからローカルブランチを更新するコマンドとなります。 つまり、 git fetch と git merge の動作を合わせて行うコマンドが git pull になるのです。 git pull リモートブランチの状態をローカルブランチに反映 git fetch リモートブランチの状態をローカルのアップストリームブランチに反映 git merge アップストリームブランチの状態をローカルブランチに反映 ローカルの作業用ブランチまで 一気通貫 で最新の状態に更新したい場合は git pull で問題ありませんが、コンフリクトが発生する際など順を追って作業したい場合にはコマンドを分割して実行するのがよいでしょう。 git pull のオプション紹介 git pull コマンドには様々なオプションがあります。 オプションは以下コマンドで参照可能です。 $ git help pull コマンドを実行すると、以下のような結果が出力されます。 NAME git-pull - Fetch from and integrate with another repository or a local branch SYNOPSIS git pull [<options>] [<repository> [<refspec>...]] DESCRIPTION Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD. More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge. <repository> should be the name of a remote repository as passed to git-fetch(1). <refspec> can name an arbitrary remote ref (for example, the name of a tag) or even a collection of refs with corresponding remote-tracking branches (e.g., refs/heads/*:refs/remotes/origin/*), but usually it is the name of a branch in the remote repository. Default values for <repository> and <branch> are read from the "remote" and "merge" configuration for the current branch as set by git-branch(1) --track. Assume the following history exists and the current branch is "master": A---B---C master on origin / D---E---F---G master ^ origin/master in your repository （中略） OPTIONS -q, --quiet This is passed to both underlying git-fetch to squelch reporting of during transfer, and underlying git-merge to squelch output during merging. -v, --verbose Pass --verbose to git-fetch and git-merge. （後略） コマンドの使い方とオプションに関する説明が詳細に出力されます。 上述の fetch と merge についての説明も記載されています。 本投稿では、このオプション群の中からいくつかを抜粋して紹介させていただきます。 オプション ショートオプション 用途 --quiet -q pull 時のメッセージを非表示にする --verbose -v ダウンロードコンテンツ の詳細を表示する --rebase -r merge を rebase に変更する --no-commit merge 時のコミットを実行しない ※以降の例ではショートオプションをしています。 pull 時のメッセージを非表示にする git pull コマンドはデフォルトで進捗状況が出力されるようになっています。 （ --progress オプションと同様の動きをします。） この進捗状況を非表示にする際には -q オプションを使用します。 $ git pull -q ダウンロードコンテンツ の詳細を表示する $ git pull -v fetch と merge コマンド双方に対してログが詳細に出力されます。 merge を rebase に変更する git pull をオプション無しで実行した場合は git fetch ＋ git merge の動作が 一気通貫 で行われますが、 -r オプションを使用することで rebase の動きに変更することができます。 $ git pull -r rebase は単体ではコミットの修正や複数のコミットを統合したい際に使用するコマンドです。 リモートにpushする前にコミットを綺麗にすることが可能ですが、過去の履歴を変更できてしまうため、複数人で開発している場合に意図的なコミットの改竄が必要でない限りは merge を使うのがよいでしょう。 （チームでルールを決めて使用している場合は全く問題ありません。） merge 時のコミットを実行しない デフォルトで git pull を実行すると新規のコミットが作成されます。 $ git pull --no-commit 上記オプションを使用すると、コミットを作成する直前に処理が中断されるため、コミットを打つ前にマージ内容を確認し、調整することが可能です。 まとめ Git入門ということで、 git pull コマンドの使い方と一部オプションをご紹介しました。 git pull はコマンド単体のオプションの他に、 fetch と merge それぞれに関連するオプションも多数用意されています。 それぞれの動きを理解することでより柔軟にバージョン管理を行うことができ、「コミットを打つ/打たない」や「履歴をそのまま残す/新しく作成する」等の認識合わせにも使用できると思いますので、よろしければ今後の参考になさってください。 　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

技術広報の yayawowo です。 SQL の中でも、良く利用されるUPDATE文ですが、 今回は SQL 入門編としまして、 UPDATE文の基本～応用をご紹介します！ ※本説明では、 PostgreSQL 9.6を利用します。 UPDATE 基本編 全レコードの更新 UPDATE文 × WHERE句 UPDATE文 × IN句 UPDATE 応用編 計算式を用いた更新 UPDATE文 × CASE文 別テーブルの値を用いた更新 別テーブルの値を条件にした更新 UPDATE まとめ ◆ 【 SQL 入門】 PostgreSQL 関連記事 ・ 【SQL入門】INSERT まとめ ・ 【SQL入門】DISTINCT 使い方 ・ RDBMSとDBMSについて【初心者向け】 ・ SQLの基本【まとめ】 ・ 【RDBMS】PostgreSQLインストール・コマンド入門編 UPDATE 基本編 UPDATE文とは、「テーブル上の列の値を更新する」際に使用する SQL 文です。 基本編に入る前に、説明時に利用するテーブルを作成します。 「 【SQL入門】DISTINCT 使い方 」でも利用した"動物テーブル"を利用します。 テーブル作成の SQL 文と結果は以下の通りです。 ◆ SQL 文 --テーブル作成SQL文 CREATE TABLE sample_animal ( animal_no integer , animal_name text, animal_breed text, animal_sex text, skill_no integer , skill_name text ); --テストデータ作成SQL文 INSERT INTO sample_animal VALUES ( 1 , ' 犬 ' , ' 柴犬 ' , ' 女 ' , 1 , null ); INSERT INTO sample_animal VALUES ( 2 , ' 犬 ' , ' 柴犬 ' , ' 男 ' , 2 , null ); INSERT INTO sample_animal VALUES ( 3 , ' 犬 ' , ' チワワ ' , ' 男 ' , 1 , null ); INSERT INTO sample_animal VALUES ( 4 , ' 犬 ' , ' プードル ' , ' 女 ' , 3 , null ); INSERT INTO sample_animal VALUES ( 5 , ' 犬 ' , ' ゴールデン ' , ' 男 ' , 2 , null ); INSERT INTO sample_animal VALUES ( 6 , ' 猫 ' , ' マンチカン ' , ' 男 ' , 2 , null ); INSERT INTO sample_animal VALUES ( 7 , ' 猫 ' , ' ペルシャ ' , ' 男 ' , 1 , null ); INSERT INTO sample_animal VALUES ( 8 , ' 猫 ' , ' ペルシャ ' , ' 女 ' , 2 , null ); INSERT INTO sample_animal VALUES ( 9 , ' 猫 ' , ' アメリカンショートヘア ' , ' 男 ' , 3 , null ); INSERT INTO sample_animal VALUES ( 10 , ' 猫 ' , ' ラグドール ' , ' 女 ' , 1 , null ); ◆ 動物テーブル animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 (null) 2 犬 柴犬 男 2 (null) 3 犬 チワワ 男 1 (null) 4 犬 プードル 女 3 (null) 5 犬 ゴールデン 男 2 (null) 6 猫 マンチカン 男 2 (null) 7 猫 ペルシャ 男 1 (null) 8 猫 ペルシャ 女 2 (null) 9 猫 アメリ カンショートヘア 男 3 (null) 10 猫 ラグドール 女 1 (null) 全レコードの更新 初めに、全レコードをUPDATEする SQL 文を見てみましょう。 ◆ 例題 動物テーブルのanimal_nameを「動物」にUPDATEする ◆ SQL 文 --全レコードをUPDATE UPDATE sample_animal SET animal_name = ' 動物 ' ; ◆ 実行結果 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 (null) 2 犬 柴犬 男 2 (null) 3 犬 チワワ 男 1 (null) 4 犬 プードル 女 3 (null) 5 犬 ゴールデン 男 2 (null) 6 猫 マンチカン 男 2 (null) 7 猫 ペルシャ 男 1 (null) 8 猫 ペルシャ 女 2 (null) 9 猫 アメリ カンショートヘア 男 3 (null) 10 猫 ラグドール 女 1 (null) 　👇 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 動物 柴犬 女 1 (null) 2 動物 柴犬 男 2 (null) 3 動物 チワワ 男 1 (null) 4 動物 プードル 女 3 (null) 5 動物 ゴールデン 男 2 (null) 6 動物 マンチカン 男 2 (null) 7 動物 ペルシャ 男 1 (null) 8 動物 ペルシャ 女 2 (null) 9 動物 アメリ カンショートヘア 男 3 (null) 10 動物 ラグドール 女 1 (null) 全レコードをUPDATEすることは、業務上あまりないかと思います。 今回は、 SQL 文の基本のキということで、ご紹介させていただきました。 UPDATE文 × WHERE句 続いて、WHERE句（条件指定）を用いたUPDATEについて見てみましょう。 ◆ 例題 動物テーブルのanimal _no が「1」の場合、animal_breedを「 土佐犬 」にUPDATEする ◆ SQL 文 --WHERE句を用いたUPDATE UPDATE sample_animal SET animal_breed = ' 土佐犬 ' WHERE animal_no = 1 ; ◆ 実行結果 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 (null) 　👇 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 土佐犬 女 1 (null) UPDATE文 × IN句 前述したWHERE句はUPDATE対象の絞り込み時に利用しますが、限定した値をUPDATEする際はどうすれば良いでしょうか？ この際に利用するのがIN句になります。 早速例題と SQL 文、実行結果を見てみましょう。 ◆ 例題 動物テーブルのanimal _no が「2」と「3」の場合、animal_sexを「女」にUPDATEする ◆ SQL 文 --IN句を用いたUPDATE UPDATE sample_animal SET animal_sex = ' 女 ' WHERE animal_no IN ( 2 , 3 ); ◆ 実行結果 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 2 犬 柴犬 男 2 (null) 3 犬 チワワ 男 1 (null) 　👇 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 2 犬 柴犬 女 2 (null) 3 犬 チワワ 女 1 (null) 上記のように、UPDATEしたいレコードに共通した条件がない場合にとても便利です。 UPDATE 応用編 では、応用編にうつります。 計算式を用いた更新 値を計算してUPDATEすることができます。 以下例題を見てみましょう。 ◆ 例題 動物テーブルのanimal _no 「1、3、5」に対し、skill _no に1を足す ◆ SQL 文 --skill_noに1を足すUPDATE UPDATE sample_animal SET skill_no = skill_no + 1 WHERE animal_no IN ( 1 , 3 , 5 ); ◆ 実行結果 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 (null) 3 犬 チワワ 男 1 (null) 5 犬 ゴールデン 男 2 (null) 　👇 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 2 (null) 3 犬 チワワ 男 2 (null) 5 犬 ゴールデン 男 3 (null) animal _no が「1、3、5」のskill _no に1が足されました。 UPDATE文 × CASE文 条件分岐を行う際に用いられるCASE文を使い、一気に値をUPDATEすることができます。 ◆ 例題 動物テーブルのskill _no が以下条件の場合、指定したskill_nameでUPDATEする skill _no ：1 → skill_name：走る skill _no ：2 → skill_name：飛ぶ skill _no ：3 → skill_name：泳ぐ 上記以外 → skill_name：なし ◆ SQL 文 --CASE文を用いたUPDATE UPDATE sample_animal SET skill_name = CASE skill_no WHEN 1 THEN ' 走る ' WHEN 2 THEN ' 飛ぶ ' WHEN 3 THEN ' 泳ぐ ' ELSE ' なし ' END ; ◆ 実行結果 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 (null) 2 犬 柴犬 男 2 (null) 3 犬 チワワ 男 1 (null) 4 犬 プードル 女 3 (null) 5 犬 ゴールデン 男 2 (null) 6 猫 マンチカン 男 2 (null) 7 猫 ペルシャ 男 1 (null) 8 猫 ペルシャ 女 2 (null) 9 猫 アメリ カンショートヘア 男 3 (null) 10 猫 ラグドール 女 1 (null) 　👇 animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 走る 2 犬 柴犬 男 2 飛ぶ 3 犬 チワワ 男 1 走る 4 犬 プードル 女 3 泳ぐ 5 犬 ゴールデン 男 2 飛ぶ 6 猫 マンチカン 男 2 飛ぶ 7 猫 ペルシャ 男 1 走る 8 猫 ペルシャ 女 2 飛ぶ 9 猫 アメリ カンショートヘア 男 3 泳ぐ 10 猫 ラグドール 女 1 走る 別テーブルの値を用いた更新 続いて別テーブルの値を使い、動物テーブルをUPDATEする SQL 文をご説明します。 初めに別テーブルとして、スキルテーブルを作成します。 ◆ SQL 文 --テーブル作成SQL文 CREATE TABLE sample_skill ( skill_no integer , skill_name text ); --テストデータ作成SQL文 INSERT INTO sample_skill VALUES ( 1 , ' 走る ' ); INSERT INTO sample_skill VALUES ( 2 , ' 飛ぶ ' ); INSERT INTO sample_skill VALUES ( 3 , ' 泳ぐ ' ); ◆ スキルテーブル skill _no skill_name 1 走る 2 飛ぶ 3 泳ぐ では、スキルテーブルの値を使い、動物テーブルのanimal_skillをUPDATEしてみましょう！ ◆ 例題 動物テーブルのskill _no が「1」の場合、スキルテーブルのskill_nameを用いて、動物テーブルのskill_nameをUPDATEする ◆ SQL 文 --別テーブルの値を用いたUPDATE UPDATE sample_animal SET skill_name = ( SELECT sample_skill.skill_name FROM sample_skill WHERE sample_skill.skill_no = 1 ) WHERE skill_no = 1 ; ◆ 実行結果 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 (null) 3 犬 チワワ 男 1 (null) 7 猫 ペルシャ 男 1 (null) 10 猫 ラグドール 女 1 (null) ＜スキルテーブル＞ skill _no skill_name 1 走る 2 飛ぶ 3 泳ぐ 　👇 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 1 犬 柴犬 女 1 走る 3 犬 チワワ 男 1 走る 7 猫 ペルシャ 男 1 走る 10 猫 ラグドール 女 1 走る 上記の通り、skill_name列がsample_skillテーブルが取得した値でUPDATEされました。 また、このように別テーブルに問い合わせる処理を「副問合せ（サブクエリ）」と言います。 別テーブルの値を条件にした更新 別テーブルの値を条件として、動物テーブルの値をUPDATEします。 ◆ 例題 スキルテーブルのskill_nameを条件とし、動物テーブルのskill_nameをUPDATEする ◆ SQL 文 --別テーブルの値を条件にしたUPDATE UPDATE sample_animal SET skill_name = ' 潜る ' WHERE skill_no IN ( SELECT sample_skill.skill_no FROM sample_skill WHERE sample_skill.skill_name = ' 泳ぐ ' ); ◆ 実行結果 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 4 犬 プードル 女 3 (null) 9 猫 アメリ カンショートヘア 男 3 (null) ＜スキルテーブル＞ skill _no skill_name 1 走る 2 飛ぶ 3 泳ぐ 　👇 ＜動物テーブル＞ animal _no animal_name animal_breed animal_sex skill _no skill_name 4 犬 プードル 女 3 潜る 9 猫 アメリ カンショートヘア 男 3 潜る skill _no が「3」のskill_nameが「潜る」にUPDATEされたことが、実行結果からお分かりいただけるのはないでしょうか。 UPDATE まとめ 「【 SQL 入門】UPDATE まとめ」はいかがでしたでしょうか？ 日頃から SQL を使った業務をされている方にとっては、基本的な内容だったかもしれません。 SQL の中でもUPDATE文は簡単な更新作業であれば気軽に使える命令ですが、様々な命令を組み合わせることがあると思います。 SQL 入門の振り返りとして、本記事をご参考いただけますと幸いです！ 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに 皆さん、こんにちは。tomo37kunです。 突然ですが、 Google が提唱している「class SRE implements DevOps」の考えを御存知でしょうか？ 「class SRE implements DevOps」は「SREはDevOpsというinterfaceの実装である」という意味を表します。 つまり、「DevOps = 思想」という定義に対し、それを具体化し実装したものがSREであるという考えになります。 昨今、注目が集まるSREの考え方を実践していく上で、定義に反する実装を行わないためにも、DevOpsの理解は避けられません。 今回はAzureを使用することで実現できるDevOps環境について調べる中で、DevOpsへの理解を深めてみようという試みです。 そのため、以下の内容に一致するものがあれば、是非一読いただけると嬉しいです。 DevOps・SREの考え方に興味がある Azureで出来ることを知りたい 目次 はじめに 目次 DevOpsとは DevOpsを実行するための5つの方針 組織のサイロの削減 エラーが発生するのを前提とする 段階的に変更する ツールと自動化を活用する 全てを計測する Azure DevOpsとは Azure DevOpsの構成要素 Azure Pipeline（CI/CD/テスト自動化ツール） Azure Boards（進捗管理ツール） Azure Repos（バージョン管理ツール） Azure Test Plans（手動テスト管理ツール） Azure Artifacts（パッケージ管理ツール） Azure DevOpsの利用料金 Azure App Serviceと併用して作る統合的なCI/CD環境 終わりに 予告 参考 DevOpsとは まずは、基本的な「DevOps(デブオプス)」の考え方についてです。 「DevOps」というのは、「Development(開発)」と「Operations(運用)」の略称を組み合わせた造語です。 ソフトウェアの開発担当と、運用担当がお互いに協力し、ソフトウェア、システムのビジネス価値を高め、その価値をエンドユーザーに迅速に届けることでよりよいサービスを作り上げていく思想のことを指します。 開発者/運用者のように分断された関係では、お互いのチームが目指す方向性にズレが生じてしまうという問題が少なからずおこります。 このような問題に対して、DevOpsの考え方を用いることで具体的に次のようなメリットが生まれます。 問題点や修正箇所の把握がしやすい ソースコード の改修などがあった際にデプロイテストが早く行えるため早い段階で問題点を見つけることができる 問題点が見つかった際のフィードバックがスムーズに行える DevOpsを実行するための5つの方針 DevOpsを実行するために必要な要素として、5つの要素が定義されています。 1. 組織のサイロの削減 2. エラーが発生するのを前提とする 3. 段階的に変更する 4. ツールと自動化を活用する 5. 全てを計測する 組織のサイロの削減 サイロとは「独立している」状態のことで、開発側・運用側のチーム同士がうまく連携できていない状態を指します。 お互いの組織に溝があることで生じる弊害を無くすため、DevOpsでは組織のサイロ化の削減を大きな指針のひとつに掲げています。 エラーが発生するのを前提とする いくら要件定義・詳細設計の段階で細かく設計したとしても、必ずシステムのエラーは発生してしまいます。 完璧なシステムはなく、エラーが発生するのを前提としてシステムの開発・運用に取り組むべきであるという考えです。 段階的に変更する 変更によって起こりうるエラーを考慮して、段階的に変更を加えることを推奨する考えです。 段階的な変更をすることにより、新規機能の追加対応、正常状態に戻す ロールバック 作業が迅速に行えるため、改善の速度を飛躍的に伸ばすこと、及びシステムの安定稼働に繋がる考えです。 ツールと自動化を活用する 開発及び運用の効率化という面で、ツールや自動化を活用することは非常に重要であるという考えです。 これは専門性や開発と運用の人的な負荷を低減することに繋がるので、サービスが拡大し、継続すればするほど初期での導入効果は大きくなります。 また、人的なエラーを起こさないための取り組みとしても非常に有効な手段です。 全てを計測する システムの運用ログやエラー検知、パフォーマンス含め、全てのデータを計測して数値化していくことが重要です。 これらのデータを開発と運用が密に運用することにより新規機能の開発やプログラム修正の際に役立つという考えです。 Azure DevOpsとは Azure DevOpsとは、2018/9/10 に Microsoft 社が発表した、DevOpsを実現するために必要なツールが揃っているオールインワンのDevOpsプラットフォームです。 以前は Visual Studio Team Services と呼ばれていたもので、プロジェクト管理、 継続的インテグレーション ＆デリバリーなど、DevOpsのためのサービス群を提供しており、アプリケーション開発の計画・開発・配信・運用のプロセスをAzure上で実現することが可能です。 通常、DevOpsを実現する環境を用意するとなると自動化・構成管理・ 進捗管理 といった多岐に渡るツールの用意が必要となるため、時間がかかってしまいます。 しかし、Azure DevOpsではこれらのツールが整っているため、スムーズに作業を行うことが可能なプラットフォームとなっています。 Azure DevOpsの構成要素 Azure DevOpsを構成するサービスは下記の通りです。 Azure Pipeline（CI/CD/テスト自動化ツール） Azure Boards（ 進捗管理 ツール） Azure Repos（バージョン管理ツール） Azure Test Plans（手動 テスト管理ツール ） Azure Artifacts（パッケージ管理ツール） これらのサービスの全て、もしくは一部を利用することで、Azure上でDevOpsのための環境を構築することができます。 Azure Pipeline（CI/CD/テスト自動化ツール） Azure Pipelineとは、Azure上でアプリケーションのビルド、デプロイ、テストを自動化する 継続的インテグレーション ＆デリバリー（CI/CD）の機能を提供するツールです。 数多くの言語に対応し、 Kubernetes やDockerなどのコンテナとも連携可能です。 対応言語は、「 Python 」、「 Java 」、「 PHP 」、「 Ruby 」、「 C++ 」、「C」、「.NET」、「Node.js」があります。 Android 、 iOS で使用することもできます。 Azure Boards（ 進捗管理 ツール） チームで作業をする際に、どのプロジェクトがどれくらい進行していて、何を作るのか、どのように作るのかという情報はとても大切となってきます。 そのような管理を可能とするのがAzure Boardsとなります。 チームで作業する上で全体の進捗の把握は必須ですが、大きなチームであればあるほど、チーム全体の状況の把握は難しくなります。 このような問題もAzure Boardsを使用すれば可能となります。 Azure Repos（バージョン管理ツール） Azure Reposとは、 ソースコード と成果物の共有とバージョン管理を行うツールです。 Gitベースの リポジトリ を提供しており、使用している 統合開発環境 ( IDE )から、接続・連携も可能なためチームメンバーと変更箇所の共有ができます。 Azure Test Plans（手動 テスト管理ツール ） Azure Test Plansとは、アプリケーションの手動でのテストを管理・支援するためのツールです。 Azure Pipelineが自動テストを支援することに対して、Azure Test Plansでは手動テストを実施する上でのテスト計画・テストケース・テスト結果などを管理する機能を提供します。 テストケースを作成せずに、状況に応じて学習を繰り返す、探索的テストも実行できます。 決められているシナリオ設定の通りにテストを行うシナリオテストも可能です。 リリース後の環境に近い設定でテストを行うことにより、リリース前に欠陥を見つけられるので早期に対応することが可能です。 Azure Artifacts（パッケージ管理ツール） Azure Artifactsは、アプリケーションを配布・公開するために、 ソースコード やライブラリをまとめたパッケージを管理するツールです。 パブリック及びプライベートのソースから「 Maven 」、「npm」、「NuGet」、「 Python 」のパッケージを共有可能です。 小さなチームでも簡単に共有を行うことができます。 また、パッケージを共有し、組み込みのCI/CD、バージョン管理、テストを自動化することが可能です。 Azure DevOpsの利用料金 Azure DevOpsの利用料金プランについては「Basic」と「Basic＋Test」の2つのプランが存在し、利用料金と機能が異なっています。 Basicプランの利用料金は5人のユーザーまでは無料となっており、6人目以降の使用は一人当たり$6/月が必要となります。 制限なく利用できるサービスは、Azure Boards、Azure Reposとなっていますが、Azure PipelinesとAzure Artifactsは条件付きでの利用料金が無料となります。 一方、Basic＋Testプランの利用料金は、1ユーザー辺り$52/月が必要となりますが、Azure DevOpsの全てのサービスを利用することが可能となっています。 また、このプランは30日間の試用期間が用意されており、無料で試すことも可能です。 Azure DevOps は単体のプラットフォームとして利用しても DevOps のための環境を構築できますが、Azure App Service と連携して利用することで 継続的インテグレーション ＆デリバ リー環 境（CI/CD 環境）とデプロイ先の環境を簡単に作成することができます。 Azure App Serviceと併用して作る統合的なCI/CD環境 Azure App Service とは、Web アプリケーションの実行環境を、インフラの設定を意識することなく簡単に作成できる Azure のサービスです。 Azure Pipeline と連携させることで、Web アプリケーションのビルド、デプロイ、テストを、アプリケーションの実行環境を含めて自動で生成できるようになります。 Azure Repos を連携させることでバージョン管理も同時に行うことができます。 Azure Test Plans や Azure Boards を組み合わせて、手動テストの管理やタスク・ 進捗管理 と連動した統合的なDevOpsを実現することも可能です。 終わりに 今回は体系的な知識を 仕入 れようということで、Azure DevOpsを使うことでできることについてまとめてみました。 DevOpsを実行するために必要な要素として、定義されている5つの要素を満たすには十分なツールが揃っていると言えるのではないでしょうか？ しかし、DevOpsの導入にはこのようなツールだけではなく文化も変えていく姿勢が必要と言われています。 DevOpsを導入しようという組織への取り組みと、ツールや開発手法の変化を並行に行うことにより、よりビジネスの価値を高められるDevOpsの考え方に近づけていくことが出来るでしょう。 予告 今回、実際に「Azure DevOps」を触った内容について触れられておらず百聞は一見に如かずということで 「今のところ他の人と使う予定がないから一人でAzureのDevOps環境を触ってみた」 と題して、Basic＋Testプランの無料の試用期間を利用して 各ツールを実際に試した記事を後日投稿させていただければと思います。 参考 Azure DevOpsとは？サービスや料金について – Azure導入開発支援 DevOpsとは？導入するメリットとAzureを活用した環境構築方法を解説 | クラウド導入・システム運用ならアールワークスへ SREとDevOpsの違いはなにか | sreake.com | 株式会社スリーシェイク エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは。 ラク ス技術広報の syoneshin です。 今回は、 ラク ス開発本部のエンジニア・デザイナーを対象に、自己研鑽についてのアンケートを実施しました。 「自己研鑽」とは一般的に、 主体的に学んでスキルや専門知識を深め、自身の向上を促すこと を指します。 当社のエンジニア・デザイナーは普段、どのくらい自己研鑽に励んでいるのか、何をしてスキルや知識を磨いているのか等、聞いてみました！ 結果、８割以上の方が何かしらの自己研鑽をしていることがわかりましたので、以下共有させていただきます！ 自己研鑽をおこなっていますか？ 一週間のうち、自己研鑽にかける時間を教えてください。 取り組んでいる自己研鑽の内容はどのようなものですか？≪複数回答可≫ 自己研鑽の目的を教えてください。 これからやってみたい自己研鑽はありますか？（フリーコメント） 技術力UP系 実務に役立つ系 終わりに 実施時期：2022年6月末 有効回答：74名 対象者： ラク ス開発本部 エンジニア・デザイナー 自己研鑽をおこなっていますか？ 「はい」が82.4％、「いいえ」が17.6％。 8割以上が何かしらの自己研鑽に励んでいるという結果になりました。 一週間のうち、自己研鑽にかける時間を教えてください。 「2～5時間」「5～10時間」「10時間以上」が、6割強を占めています。 「2～5時間」が42.4％、次に「1～2時間」が25.4％、「5～10時間」が15.3％と、 一週間にきちんと自己研鑽の時間を取っている方が一定数伺えます。 開発メンバーがおすすめする「エンジニアの勉強法」 の記事にも参照している、「IT人材白書2020」アンケートで出ていた数字と比べ、 ラク スのエンジニア・デザイナーは、自己研鑽・自主的な勉強にあてる時間が多いことがわかりました！ 取り組んでいる自己研鑽の内容はどのようなものですか？≪複数回答可≫ 「専門書を読む」「ビジネス書」の回答が目立つ結果に。 ラク スには書籍の貸出サポートもありますので、利用されている方も一定数いるということでしょうか。 また、専門書だけでなくビジネス書を読む人が多いのは当社の特徴かもしれません。 その他、3番目に「プログラミング」、「e-learning等の動画視聴」、「語学の勉強」と続きました。 自己研鑽の目的を教えてください。 「現在の業務に活かすため」が50％、続いて「今後のキャリアの選択肢を広げるため」が20％、「新しいことにチャレンジするため」が18.3％という結果になりました。 その他には、「技術の幅が広がることが単純に楽しい」「自身向上のため」「登壇の準備で必要なため」と、自己研鑽に対して前向きな回答が目立ちました。 これからやってみたい自己研鑽はありますか？（フリーコメント） ここまで取り上げたもの以外で、今後挑戦したい自己研鑽についても聞いてみました！ 普段から興味のある技術への取り組みのほか、マネジメントの実務力UPに興味を持っている人もいるようです！ 技術力UP系 個人開発・ AWS の習熟 新しい プログラミング言語 やMWを利用した開発 自作アプリの制作 Kubernetes のCRD作成、コードリーディング OSS コントリビュート kubernetes , go ARプログラミングの習得 実務に役立つ系 コーチン グ研修受講 MBA などの学位を取得 これらの手段としては、書籍（技術書／Audiobook）はもちろん、社外勉強会参加などの声もありました。 終わりに 今回の質問は以上になります。 ラク スで働くエンジニア・デザイナーについて、少しでもイメージできましたでしょうか？ 当社では社員の自己研鑽活動を支援するため、以下のような取組みを実施しております。 当社の自己研鑽支援の事例にご興味ございましたら、ぜひ詳細もご覧いただけると幸いです。 職位・等級別研修の実施 資格取得、書籍購入・貸出のサポート 定期的な社内読書会・LT会の開催 社内でDDD(ドメイン駆動設計)読書会を開催しました Tailwind CSS 社内勉強会【まとめ】 外部イベントへの登壇支援 【イベントレポート】JJUG CCC 2022 Springに登壇・協賛しました！ PHPerKaigi 2022【参加レポート】 社外向け勉強会やLT会の主催 ぜひ下記の記事も読んでみてください！ ◆ 関連ブログ◆ ・ラクスエンジニア・デザイナーに聞いてみた【休日・休暇の過ごし方】 ・ラクスの福利厚生をご紹介！ ・ラクスのSaaSプロダクト紹介【12種類まとめ】 ・【株式会社ラクス】SaaSプロダクト別の技術スタックを一挙公開！ ・開発メンバーがおすすめする「エンジニアの勉強法」 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは！気づけば ラク ス入社5年目の aa_crying です。 本日は、現在学習中のTypeScriptの基礎についてお話しできればと思います。 現在 ラク ス開発部では、部署間での技術知識共有のためTypeScriptの勉強会(読書会)を開催しています。 TypeScriptを先行して導入した部署から、導入を検討している部署向けに知識を展開することが目的です。 まずは指定されたページを読み、その後に読んで理解した内容やわからなかったことを周りのメンバーと議論する形をとっています。 勉強会で読んでいる書籍はこちらになります。 www.amazon.co.jp 今回は、勉強会で得たTypeScriptの入門知識を皆さんに共有できればと思い、記事にさせていただきました。 アジェンダ は以下の通りです。 TypeScriptとは TypeScriptのインストール トランスパイル TS Playground TypeScript入門 TypeScriptの『型』について 型推論 型ガード 便利だけど使わないほうがよい「any」 補足 「unknown」 おわりに TypeScriptとは TypeScriptは、 Microsoft が開発した JavaScript に静的型付け機能が追加された言語です。 JavaScript とは異なる言語ではなく、型に関すること以外のコードについては通常の JavaScript と同様の構文を使って記述することができます。 TypeScriptは JavaScript の機能をすべて利用できることから、"スーパーセット"と呼ばれます。 型の異なる関数呼び出しや代入を コンパイル 時に検出することによりプログラムの品質を高めることができます。 TypeScriptファイル( .ts)をそのまま実行することはできず、 JavaScript ファイル( .js)に コンパイル する必要があります。 TypeScriptのインストール Node.jsとnpmがインストールされている環境でnpmコマンドでインストールを実施します。 $ npm install -g typescript # Node.js, npmがインストールされていることが前提 $ tsc -v Version 4 . 5 . 4 tsc -v でバージョンが返ってくればインストールは完了です。 指定したバージョンをインストールしたい場合は typescript@4.5.4 のように@の後ろにバージョンを指定してください。 トランスパイル 先ほどもお伝えした通り、TypeScriptファイル( .ts) をそのまま実行することはできず、 JavaScript ファイル( .js)に コンパイル する必要があります。 この作業をトランスパイルと呼びます。 内容としては簡単で、作成したTypeScriptファイル(*.ts)に対して tsc コマンドを実行するだけです。 ディレクト リ直下のすべてに対して実施したい場合は、 *.ts を指定すれば可能です。 $ tsc sample.ts # sample.js ファイルが作られます。 $ tsc *.ts TS Playground ここまでTypeScriptの導入方法・実行方法を記載しましたが、TypeScriptでコードを書いて動作を確認したいだけであれば、 Microsoft が公式ページで公開している「TS Playground」を使用することをお勧めします。 (※トランスパイルも非同期でやってくれ、「.JS」タブで内容を確認できます。) www.typescriptlang.org TypeScript入門 準備が整ったので、入門編開始です。 勉強会(読書会)では、 JavaScript とTypeScriptの違いにフォーカスし型の部分を中心に読んでいるため、TypeScriptの基本的な構文の説明等は省き、型の部分に絞ってお伝えできればと思います。 TypeScriptの『型』について JavaScript では型を事前に宣言することがないので誤った型のデータを関数に渡している場合、実行タイミングになってようやくエラーであることがわかります。 しかし、TypeScriptでは型を宣言するだけではなく事前に コンパイル により型チェックを行うので、型に問題がある場合はコードを動作させる前に問題を把握することができます。 そのため、TypeScriptは「型安全な言語」と呼ばれています。 またエディタによっては型に関する問題がある場合、コードの記述中にエラーメッセージで問題がある箇所を示してくれるのでコード記述中に気付いて修正を行うことができます。 const str: string = "hoge" ; //① const str2 = "hoge" //② 上記①の string の部分は 型注釈 といい、strがstring型であることを示しています。 型注釈は②のように省略することが可能です。 なぜ省略が可能かというと、TypeScriptには 型推論 という機能があるからです。 型推論 TypeScriptには周辺情報や文脈から自動的に型を推測してくれる機能があります。 これを 型推論 と呼びます。 以下に簡単な例を示します。 let x = 100; let str = "aaa" ; x = "bbb" // xはnumber型に推論されるためエラー str = 200 // strはstring型に推論されるためエラー 想定通りに推論してくれることが多いですが、期待している型と違っているケースもあるため、推論された型が想定通りかはチェックする必要があります。 また、関数の戻り値も関数内の文脈から 型推論 してくれます。 function getAddtion(x: number, y: number) { return x + y; } 上記では引数2つの型がnumber型で、それらを足し合わせた結果を返す関数であるため、戻り値もnumber型に推論されます。 以下のように関数内の条件によって戻り値の型が変わる場合は、Union型で推論してくれます。 function numberOrString(x: number) { if (x < 10) { return String (x); } return x; } 推論結果 function numberOrString(x: number): string | number 以上のように便利でコード量も削減できるTypeScriptの 型推論 ですが、 より複雑な関数を書く時は可読性の面でも 型推論 を使わずに型を明記するようにしたほうが良いのかなと個人的には思います。 型ガード 型推論 によって型を判別してくれるのはTypeScriptの便利な機能の1つではありますが、Union型等で2つ以上の型を引数に持つ場合、型の曖昧さは残ります。 これを回避するために、以下のように条件判定で型の絞り込みを行うことが多いです。 このようなコードのことを型ガードと呼びます。 function numCut(num: number | string) { if ( typeof num === "string" ) { return num.charAt(0); } else { return String (num).charAt(0); } } Union型でnumberとstringを引数として受け付けていますが、 charAt() はstringに対してしか使用できないため、型ガードをつけずに return num.charAt(0); だけ記載するとエラーになります。 そのため、 typeof 等を使って処理する型を制限する必要があります。 「この型の時だけこの処理を行う」が実現できるのが、型ガードです。 typeof だとプリミティブ型については判定できますが、オブジェクトはobject型であることまでしか判定ができません。 typeof null の結果がobjectになるという例外的な仕様もあるため要注意です。 (object型：プリミティブ型以外の型は全てobject型に分類される) 便利だけど使わないほうがよい「any」 TypeScriptでは、仕様上定義されてはいますがTypeScriptの型の良さが失われてしまう型や関数が存在するため、その1例を紹介します。 TypeScriptのany型は、どんな型でも代入を許す型です。 プリミティブ型であれオブジェクトであれ何を代入してもエラーになりません。 let value: any; // 以下どれもコンパイルエラーにならない value = 1; value = "string" ; value = false ; 上記の通り型チェックも行われないため、どんな値を入れても コンパイル エラーにはなりません。 また、以下のように引数の型注釈を省略した場合、 型推論 によってanyと判別されるパターンもあります。 toUpperCase() はStringに対して使用できるメソッドですが、name がany型と推論され型チェックを通ってしまっています。 この関数に数値を代入するように記載をしても、any型であるため コンパイル エラーは出ず、実行時エラーとなってしまいます。 function nameToUpper(name) { console.log(name.toUpperCase()); } nameToUpper(12345); このケースは型注釈を省略せずに記載するほか、設定ファイル tsconfig. json にて noImplicitAny: true を設定することで、any型を推論した場合にエラーを表示するようにできるため、設定することをお勧めします。 any型はTypeScriptの特徴である型安全性を度外視した型になるため、書籍でも 『最凶の危険性を誇る機能』 として紹介されており、anyの使用はできるだけ避けるようにとのことです。 しかし、 JavaScript をTypeScriptで書き直す際などはいったんany型で定義して実行できる状態を作ってから型定義していくやり方がよさそうで、本コードとしては残すべきではないにしろ、開発途中では役に立ちそうだなと思いました。 補足 「unknown」 同じくどのような値も代入できる型として、unknown型があります。 unknown型は代入はなんでも可能ですが、メソッドやプロパティを使おうとすると、 Object is of type 'unknown'. というエラー文言が出て使用できません。 function nameToUpper(name: unknown) { console.log(name.toUpperCase()); } nameToUpper(1); こちらはanyを使うより安全ではありますが、メソッドやプロパティを使用できないため扱いづらいという印象が強いです。 おわりに 以上、TypeScriptの入門として主に『型』に関する内容を記載させていただきました。 これからTypeScriptの学習を考えている方の支えになれば幸いです。 勉強会はまだ続いていくので、また機会があれば得た知識を共有できればと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは。 ラク ス技術広報の syoneshin です。 今回は、 ラク ス開発本部のエンジニア・デザイナーを対象に、休日・休暇の過ごし方についてアンケートを実施しました。 休日の過ごし方、何をして過ごすのか、理想の長期休暇の過ごし方などお聞きしましたので、 結果を共有させていただきます。 休日に入る前に、休日の予定を立てておく？ 休日の過ごし方で、重視するのはどちらですか？ 休日の過ごし方はインドア派ですか？ アウトドア派ですか？ 休日はどんなことをして過ごすことが多いですか？≪複数回答可≫ 理想の長期休暇（GW・夏季休暇・年末年始）の過ごし方を教えてください！（フリーコメント） 終わりに 実施時期：2022年6月末 有効回答：74名 対象者： ラク ス開発本部 エンジニア・デザイナー 休日に入る前に、休日の予定を立てておく？ 「予定を立てておくことが多い」41.9％、「あまり予定を立てない」40.5％。 「毎回予定を立てておく」6.8％、「ほとんど予定を立てない」10.8％という結果になりました！ 休日の過ごし方で、重視するのはどちらですか？ 「心身を休める・リラックス」が55.6％と、半数以上を占める結果となりました。 次に、「楽しむ・盛り上がる」27.8％、「どちらでもない」9.7％。 「その他」には、「子ども次第」「1日の大半は子どもの勉強を見てます」「子どもが家で暇にならないように」「子どもが楽しめるか」など、家族重視の過ごし方をされる方が目立ちました。 休日の過ごし方はインドア派ですか？ アウトドア派ですか？ インドア派52.7％と、インドア派の方が多い傾向にあるようです。 次いで「どちらでもない」27.0％、「アウトドア派」20.3％という結果になりました。 一緒に暮らすご家族に合わせてという方も多いのかもしれませんね！ 休日はどんなことをして過ごすことが多いですか？≪複数回答可≫ 「趣味をする」が最も多く64.9％、次いで「買い物」48.6％、「のんびり過ごす」47.3％という結果になりました！ 4番目に多い「家事をする」は45.9％。 また、その他にご記入いただいた方は「子どもと一緒に過ごす」「子どもの学習指導」「子どもの習い事」など、お子様関係の回答がほとんどでした。 インドア派でもアウトドア派でも、充実した休日を過ごされる方が多いようです！ 理想の長期休暇（GW・夏季休暇・年末年始）の過ごし方を教えてください！（フリーコメント） 最後に、GW・夏季休暇・年末年始などの長期休暇中の理想の過ごし方を聞きました！ ラク スは、GW・夏季休暇・年末年始はもちろん、入社日に15日の有給休暇が支給されるなど、休暇も取りやすい環境です。 帰省 国内旅行 海外旅行 友人と出かける 趣味に没頭する コロナが落ち着いたので、2～3泊程度で妻とバスツアーなどに参加したい。 1回旅行に行って、あとは家でゲームや勉強など 最低１日は出かけずに家でのんびりする日を作る 旅館やホテルに缶詰になって読書・勉強 ご飯作りはお弁当を発注して手を空けて、子どもの教科別学習＆課外学習の指導、寝かせてからは自分の趣味で DIY or - プログラム制作。家で過ごしたい。 子供と一緒に過ごす 家族とゆっくり過ごす 溜まっているタスクを消化する 最初と最後はゆっくり過ごす、中頃ぐらいに1泊2日ぐらいの小旅行 ずっとごろごろする 普段の週末と特段変わりない 非日常的なことをする 趣味に没頭し、時間を気にせず眠くなったら寝る サッカー三昧 長期休暇中は完全にオフにしたいと思います。（実際にそうしています。） 登山＋プチ旅行 旅行かライブに行きます。 コロナで会えていない人に会いに行きたい ペンギンを眺める 様々な過ごし方をいただきましたが、「旅行」関係がかなり多く（重複した回答が多数ありました）、「帰省」なども目立ちました。 ここ数年旅行や帰省を控えていた方も、折を見て理想の休暇を実現できるといいですね！ 終わりに 今回の質問は以上になります。 ラク スで働くエンジニア・デザイナーについて、少しでもイメージできましたでしょうか？ 最後までお読みいただきありがとうございました！ ◆ 関連ブログも合わせてご確認ください！ ラクスの福利厚生をご紹介！ ラクスのSaaSプロダクト紹介【12種類まとめ】 【株式会社ラクス】SaaSプロダクト別の技術スタックを一挙公開！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

技術広報の yayawowo です。 皆様、 SQL のDISTINCTはご存知でしょうか？ DISTINCTを覚えることにより、 SQL の実行結果がとても見やすくなります！ 本記事では、DISTINCTの基本的な使い方、GROUP BYとの違いなどを説明していきたいと思います。 DISTINCTをマスターし、業務効率化を目指しましょう！！ ◆ PostgreSQL 関連記事 ・ 【SQL入門】INSERT まとめ ・ 【SQL入門】UPDATE まとめ ・ RDBMSとDBMSについて【初心者向け】 ・ SQLの基本【まとめ】 ・ 【RDBMS】PostgreSQLインストール・コマンド入門編 DISTINCTとは DISTINCTの使い方 DISTINCTの基本的な使い方 レコード単位に重複行をまとめる COUNTと組み合わせる GROUP BYとの違いは？ DISTINCT 使い方 まとめ DISTINCTとは DISTINCTとは、 SQL コマンドの一つです。 SELECT文にて出力した実行結果の重複レコードを1つにまとめることができます。 以下、DISTINCTを使った際の実行結果例になります。 DISTINCT 🙅 動物 種類 性別 犬 柴犬 女 犬 柴犬 女 猫 マンチカン 男 DISTINCT 🙆 動物 種類 性別 犬 柴犬 女 猫 マンチカン 男 DISTINCTの使い方 では、DISTINCTの使い方をご説明します。 今回は PostgreSQL 9.6を利用し、ご説明させていただきます。 DISTINCTの基本的な使い方 まず初めに、 DISTINCTの基本的な使い方 についてです。 DISTINCTは、以下のようにSELECT文と組み合わせて使います！ SELECT DISTINCT 列名 FROM テーブル名 ; ではまず、サンプルデータの作成をしていきます。 今回は、動物テーブルを使っていきます。 ◆ SQL 文 --テーブル作成 CREATE TABLE sample_animal ( animal_no integer , animal_name text, animal_breed text, animal_sex text ); --テストデータ INSERT INTO sample_animal VALUES ( 1 , ' 犬 ' , ' 柴犬 ' , ' 女 ' ); INSERT INTO sample_animal VALUES ( 2 , ' 犬 ' , ' 柴犬 ' , ' 男 ' ); INSERT INTO sample_animal VALUES ( 3 , ' 犬 ' , ' チワワ ' , ' 男 ' ); INSERT INTO sample_animal VALUES ( 4 , ' 犬 ' , ' プードル ' , ' 女 ' ); INSERT INTO sample_animal VALUES ( 5 , ' 犬 ' , ' ゴールデン ' , ' 男 ' ); INSERT INTO sample_animal VALUES ( 6 , ' 猫 ' , ' マンチカン ' , ' 男 ' ); INSERT INTO sample_animal VALUES ( 7 , ' 猫 ' , ' ペルシャ ' , ' 男 ' ); INSERT INTO sample_animal VALUES ( 8 , ' 猫 ' , ' ペルシャ ' , ' 女 ' ); INSERT INTO sample_animal VALUES ( 9 , ' 猫 ' , ' アメリカンショートヘア ' , ' 男 ' ); INSERT INTO sample_animal VALUES ( 10 , ' 猫 ' , ' ラグドール ' , ' 女 ' ); 上記 SQL 文により、動物テーブルが完成しました。 SELECT文で中身を見てましょう。 ◆ SQL 文 --全件検索 SELECT * FROM sample_animal ; ◆ 実行結果 animal _no animal_name animal_breed animal_sex 1 犬 柴犬 女 2 犬 柴犬 男 3 犬 チワワ 男 4 犬 プードル 女 5 犬 ゴールデン 男 6 猫 マンチカン 男 7 猫 ペルシャ 男 8 猫 ペルシャ 女 9 猫 アメリ カンショートヘア 男 10 猫 ラグドール 女 では動物テーブルを使い、DISTINCTを使う場合と使わない場合を比較してみたいと思います！ 動物名（animal_name）を検索します。 DISTINCT 🙅 ◆ SQL 文 ---動物名（animal_name）の検索 SELECT animal_name FROM sample_animal ; ◆ 実行結果 animal_name 犬 犬 犬 犬 犬 猫 猫 猫 猫 猫 DISTINCT 🙆 ◆ SQL 文 ---動物名（animal_name）の検索 SELECT DISTINCT animal_name FROM sample_animal ; ◆ 実行結果 animal_name 犬 猫 いかがでしょうか？ DISTINCTを使うことにより、重複レコードを1つまとめることができました。 動物テーブルにどんな動物がいるのか知りたい際に、とても便利です。 レコード単位に重複行をまとめる DISTINCTはレコード単位に複数行をまとめることもできます。 今回も動物テーブルを使い、DISTINCTを使う場合と使わない場合を比較してみたいと思います！ DISTINCT 🙅 ◆ SQL 文 ---動物名（animal_name）、動物種類（animal_breed）の検索 SELECT animal_name,animal_breed FROM sample_animal ; ◆ 実行結果 animal_name animal_breed 犬 柴犬 犬 柴犬 犬 チワワ 犬 プードル 犬 ゴールデン 猫 マンチカン 猫 ペルシャ 猫 ペルシャ 猫 アメリ カンショートヘア 猫 ラグドール DISTINCT 🙆 ◆ SQL 文 ---動物名（animal_name）、動物種類（animal_breed）の検索 SELECT DISTINCT animal_name,animal_breed FROM sample_animal ; ◆ 実行結果 animal_name animal_breed 猫 ラグドール 犬 柴犬 犬 チワワ 猫 ペルシャ 猫 アメリ カンショートヘア 猫 マンチカン 犬 ゴールデン 犬 プードル ※ 並び順についての注意点🚨 DISTINCTを使用する際、内部でソートしてから重複を削除するという処理が働くため並び順がおかしくなります。 もし並び順を整えたい場合は、ORDER BYを使った構文に書き換えてください。 COUNTと組み合わせる 次はひと手間加えて、レコード件数の取得をやってみましょう！ レコード件数の取得は、DISTINCTとCOUNTを使って記述します。 まず初めに、 DISTINCTする列が1つの場合にのみ有効な取得方法をご紹介 します。 COUNT 🙅 ◆ SQL 文 ---動物名（animal_name）の検索 SELECT DISTINCT animal_name FROM sample_animal ; ◆ 実行結果 animal_name 犬 猫 COUNT 🙆 ◆ SQL 文 ---出力結果の件数検索 SELECT COUNT ( DISTINCT animal_name) FROM sample_animal ; ◆ 実行結果 count 2 次に、 DISTINCTする列が複数の場合に有効な取得方法をご紹介 します。 動物名（animal_name）と動物種類（animal_breed）の検索を例とします。 CONCATを使い列と列を繋ぎ合わせ、重複レコードを1つにまとめてます。 まずは、COUNTを使わない場合の SQL 文と実行結果を見てみましょう。 COUNT 🙅 ◆ SQL 文 ---CONCATを使った検索 SELECT DISTINCT CONCAT (animal_name,animal_breed) FROM sample_animal ; ◆ 実行結果 count 猫 マンチカン 犬チワワ 犬プードル 猫 アメリ カンショートヘア 犬柴犬 猫 ラグドール 猫 ペルシャ 犬ゴールデン 上記実行結果の通り、動物名（animal_name）と動物種類（animal_breed）が結合され、重複レコードもまとめられた状態で取得されました。 では次に、この取得結果の件数を確認するため、COUNTを使ってみましょう。 COUNT 🙆 ◆ SQL 文 ---出力結果の件数検索 SELECT COUNT ( DISTINCT CONCAT (animal_name,animal_breed) ) FROM sample_animal ; ◆ 実行結果 count 8 出力結果の件数を確認することができました。 GROUP BYとの違いは？ DISTINCTと同様、重複レコードを削除する際にGROUP BYを使用するケースもあります。 違いは以下の通りです。 DISTINCT ・・・重複レコードを排除した形で結果を出力 GROUP BY・・・グループにまとめた結果に対し、何らかの処理を加え出力 SQL 文、実行結果の違いも以下にまとめておきます。 DISTINCT 🙆 DISTINCTを使った例は以下の通りです。 ◆ SQL 文 ---DISTINCTを使った検索 SELECT DISTINCT animal_name FROM sample_animal ; ◆ 実行結果 animal_name 犬 猫 GROUP BY 🙆 上記DISTINCTの実行結果と同じ取得も、GROUP BYでできます。 ◆ SQL 文 ---GROUP BYを使った検索 SELECT animal_name FROM sample_animal GROUP BY animal_name ; ◆ 実行結果 animal_name 犬 猫 では、犬と猫のカウントをしたい場合はどうすればよいでしょうか？ このように、グループにまとめた結果に対し、何らかの処理を加え出力したい場合はGROUP BYを利用します。 DISTINCTでは、何らかの処理を加えての出力はできません。 ◆ SQL 文 ---GROUP BYを使った出力件数の検索 SELECT animal_name, COUNT (animal_name) FROM sample_animal GROUP BY animal_name ; ◆ 実行結果 animal_name count 犬 5 猫 5 実際、DISTINCTを使う頻度は高くないと思います。 しかしがなら、レコード単位に重複行を簡単にまとめたい！と思った際に簡単に活用することができます。 DISTINCTとGROUP BYのどっちを書けばよいか悩んだ際は、実行計画や実速度を比較して適切な選択をいただけますと幸いです。 DISTINCT 使い方 まとめ DISTINCTの使い方はいかがでしたでしょうか？ DISTINCTは、SELECT文を利用する際に重複レコードを1つにまとめることができるため、覚えておくととても便利な構文です。 今回初めて使った方や、使い方を忘れてしまった方にとって、本内容が少しでもご参考となれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

技術広報の yayawowo です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます！ 今年度2回目となる ラク スMeetupは、 『 SaaSプロダクト開発をリードするデザインとフロントエンド 』 でした！ テーマは『UIデザインとフロントエンド』です。 当社の現場最前線のエンジニア/デザイナーから普段の活動や開発・運用で得た知見などの技術情報をお届けしました！ なお、本イベントは以下のような方にオススメとなっております。 ◆ こんな方にオススメ！ ・UIデザインチーム、フロントエンドチームに興味がある方 ・息の長いシステムの リファクタリング を検討している方 ・ビジネスサイドへの提案を始めようとしている方 ・フロントエンド、バックエンド分離を予定している方 ・ SaaS 開発に携わるエンジニア/デザイナーの話が聞きたい 発表の紹介 プロダクトデザイン組織の新しい取り組み 既存システムのフロントエンド・バックエンド分離 7月開催！おすすめ技術イベント ラクスのエンジニア/デザイナーと話をしてみたい方へ 終わりに 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ イベントの詳細は以下をご確認ください。 rakus.connpass.com プロダクトデザイン組織の新しい取り組み 登壇：小野田 純也 [所属：プロダクトデザイン課／担当プロダクト： 楽楽電子保存 、 楽楽明細 、 楽楽労務 ] speakerdeck.com 1本目は、小野田さんより『プロダクトデザイン組織の新しい取り組み』をご紹介いただきました！ プロダクトデザイン課のミッションである「プロダクト開発の中心となって顧客課題を解決する優れたUXを生み出す」のもと、組織横断チームとして ラク スの様々なプロダクト開発に積極的に関わっています。 以下について、発表いただきました。 プロダクトデザイン課についての紹介（ミッション・ビジョンについても紹介） 新サービス開発における、共通UIライブラリを用いたデザイン作成とFEとの関わり（楽楽電子保存） ペルソナ設定の取り組み（ChatDealer） 改善のためのユーザーインタビュー実施（配配メール ） ◆ ラク スのデザイン情報については、以下をご確認ください！ career-recruit.rakus.co.jp 既存システムのフロントエンド・バックエンド分離 登壇：関 淳志 [所属：フロントエンド開発課／担当プロダクト： ChatDealer ] speakerdeck.com 2本目は、フロントエンド開発課の関さんによる発表です。 ChatDealerでは、Laravelを採用しております。 その中でもviewは、フロントエンドとバックエンドのコードが混在し密結合になっており、開発する上で様々な問題が出てきました。 本発表では、それらを改善するべくフロントエンドとバックエンドの ソースコード 分離を行うことを決意し、提案から実装に至るまでの過程についてお話ししました。 フロントエンド/バックエンドを分離しようと考えた経緯 ビジネスサイドへの提案 ソースコード 分離の実施 ソースコード の分離を行い、見えてきた今後の課題　 7月開催！おすすめ技術イベント ラク スでは、定期的にエンジニア/デザイナー向けの技術イベントを開催しております。 その中でも7月に開催する、技術イベントをご案内いたします。 ◆ エンジニアの勉強法ハックLT- vol.9 techplay.jp ◆ おすすめの技術書 LT会 - vol.4 techplay.jp ◆ 【 ラク スDev Team Talk 】小さく試して大きく育てるチームづくり techplay.jp ◆ 開発×テスト LT会 - vol.3 techplay.jp ◆ エンジニアリング組織あれこれLT techplay.jp ◆ 【 ラク スDev Team Talk 】急成長プロダクト組織のマネジメント強化 techplay.jp ◆ UI/UXデザイナーLT会 - vol.8 techplay.jp ◆ リファクタリング LT 〜毎日こつこつちょっとずつ〜 techplay.jp 1つでもご興味があるものがございましたら、お気軽にご参加ください！ 採用イベントも開催中！こちらも合わせてご確認ください。 ・ 7/22(金) UIデザイナーの仕事紹介／カジュアル説明会 ・ 7/26(火) フロントエンドエンジニアの仕事紹介／カジュアル説明会 ラク スのエンジニア/デザイナーと話をしてみたい方へ 当社では、一緒に働くエンジニア/デザイナーを積極的に募集しております！ 現在募集している職種は、以下の通りです。 ◆ UIデザイナー career-recruit.rakus.co.jp career-recruit.rakus.co.jp ◆ Webデザイナー career-recruit.rakus.co.jp ◆ フロントエンドエンジニア career-recruit.rakus.co.jp career-recruit.rakus.co.jp 「まだ応募する段階では…」 という方は、是非 カジュアル面談 もご検討ください！ 【こんな方におすすめ】 ポジションが経験にマッチするか確認したい 働き方/環境・体制/事業・プロダクト/文化/制度を詳しく知りたい 応募前に選考の概要を聞きたい（人物像、基準など） エンジニア・デザイナーの人となりを知りたい 以下申込フォームとなります。 rakus.hubspotpagebuilder.com 「イベントで登壇していた●●さんと話してみたい・・・」 などご要望がありましたらその旨をご記入の上、お申込みください！ お気軽にどうぞ 😊 終わりに 『 SaaS プロダクト開発をリードするデザインとフロントエンド』はいかがでしたでしょうか？ 最前線で活躍しているエンジニア/デザイナーからプロダクトデザイン組織の取り組みや、 フロントエンドとバックエンドの分離体験を発表させていただきました。 SaaS 開発に携わるエンジニア/デザイナーの皆様が、一つでもご参考になる情報がありましたら幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんなことをお話しします 参加申込方法 ◆TECH PLAY これまでの「組織・チーム作り」発表まとめ ラクスの開発組織戦略 横断チーム立ち上げ 人材育成・学習 こんにちは、技術広報のnobu_msです。 皆様のエンジニア・デザイナー組織では、チームビルディングを行っていますか？ 今回 ラク スでは、開発組織（エンジニア・デザイナー）のチーム作り事例を紹介するイベント「 ラク ス Dev Team Talk 」を開催します！ こんなことをお話しします プロダクトフェーズにあわせた組織づくり 技術 ブランディング ・コミュニティづくり 開発プロセス や プロダクトマネジメント 育成・オンボーディングの取り組み 成長・学習機会の提供 マネジメントの仕組化 業務効率化　など 参加申込方法 イベントに参加したい！という方は、TECHPLAYからお申込みをお願いします！ ◆TECH PLAY ・7/11(月)19:00～ 【 ラク スDev Team Talk 】デザインチーム 業務とマネジメントの「仕組化」をキーワードにデザイン専門組織の取り組みを紹介！ techplay.jp ・7/19(火)19:00～ 【 ラク スDev Team Talk 】小さく試して大きく育てるチームづくり 開発プロセス 、エンジニア文化、組織づくりなど、関西発のさまざまな事例を紹介！ techplay.jp ・7/25(月)19:00～ 【 ラク スDev Team Talk 】急成長プロダクト組織のマネジメント強化 導入件数年間170%成長の楽楽明細。開発体制強化・組織再編の取り組みを紹介！ techplay.jp 各回とも最前線のエンジニア リングマ ネージャー、デザインマネージャーが参加。 さまざまな現在進行形の取り組み事例をざっくばらんにご紹介します。 情報交換、質問、交流機会として是非お気軽にご参加ください！ イベントでお会いできることを楽しみにお待ちしております！ これまでの「組織・チーム作り」発表まとめ ラク スのイベントでは定期的に、エンジニアやデザイナーが組織戦略やチーム作りをテーマに発表しています！ ここではその一部をご紹介します。こちらも是非ご覧ください！ ラク スの開発組織戦略 speakerdeck.com speakerdeck.com speakerdeck.com 横断チーム立ち上げ speakerdeck.com speakerdeck.com 人材育成・学習 speakerdeck.com speakerdeck.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめまして。 顔の濃さが唯一の アイデンティティ のインフラエンジニア、m_yamaです。 ラク スに入社して1年、関わっている2つのサービスでTerraformをよく触ってるので、まとめてみました。 この記事さえ読めば、きっとあなたもTerraform中級者です。 （ちょっと盛った） （自分が中級者みたいでおこがましい） （精進します） 目次 目次 Terraformとは ざっくり理解するTerraformの全体像 Terraformの参考コード（EC2編） リソースをコード化するメリットって？ AnsibleやChef、Puppetとの違い Terraformの使い方 基本的にはこの2つ「plan」「apply」 既存リソースをTerraform管理する「import」 なにをTerraform管理しているかを確認する「state list」 Terraformの3大便利ツール 1. 既存環境を楽にTerraform管理する「Terraformer」 2. GUIでTerraformコードを生成できる「former2」 3. profile変更が楽になる「direnv」 まとめ Terraformとは Terraformは、いわゆる IaC(Infrastracture as Code) を体現するツールの一つで、インフラ環境をコード化できるスグレモノです。 たとえば、複数のEC2を同じ設定で起動する必要があったり、他人が作ったEC2のコピーを作る場合、「 そんなとこ気付かねえよ！ 」みたいな、奥底で設定された値を間違えてサーバを作り直す、なんて経験をしたことがあると思います。 (EC2のパブリックIPの自動割り当てにチェックを入れずに作成してしまい、 yum updateができずに泣く泣く作り直す、なんてことは良くあります) EC2のアクションを見ていくと、「 インスタンス の設定」や「セキュリティ」など、ひとつのEC2につき 設定ページへのリンクが32個 もありました。 全部設定する必要はないものの、全部のリソースの全ページを確認してたら日が暮れます。 Terraformでコード化していれば、コマンドぽちでポコポコ同じ設定のEC2が立ち上がるので、同じ設定が簡単に再現できます。 そのほか、 以下のようなメリット があります。 テスト環境・ステージング環境・本番環境など、どれか一つあればほかの環境の構築が簡単 試験的に設定を変更しても、すぐに元に戻せる（性能試験がしやすい） 間違えて削除してしまったリソースを、同じ設定ですぐに復元できる AWS は GUI がガラッと変更されて戸惑いやすいが、コード化されてれば関係ない ※ AWS を例に出していますが、 GCP やAzure、オンプレまでいけちゃうマルチなツールです。 ざっくり理解するTerraformの全体像 Terraformは、EC2などのリソースをコード化して、「 tfstate 」というファイルに反映することでリソースの管理をします。 ※ tfstateファイルはリソースのメタ情報など全てが記載されたファイルなので、ローカルではなく S3などに保管し、さらにバージョニングしておくと安心 です。 Terraformを実行する大まかな流れは以下の通りです。（各Terraformコマンドは後述します） EC2などのリソースをコード化する(*.tfファイルを作成する) コード化したリソースが、 すでにある場合：TerraformimportすることでTerraform管理下に置かれる(tfstateに追記する) ない場合：Terraformapplyすることでリソースを作成し、Terraform管理下に置かれる 以下、リソースを変更する場合は、コードを編集してTerraformplanで確認し、Terraformapplyで反映する（+ tfstateファイルの更新） Terraformの参考コード（EC2編） 参考までに、EC2のTerraformコードを書いてみました。 例えばこの場合、 以下のようなメリット があります。 amiを明記することでバージョンを統一でき、バージョン違いによる微妙な挙動の違いを防げる stagingなど別環境を作る際、PrivateIPの ホスト部 を統一しやすい（IPから中身がイメージしやすくなる） EC2やEBSで忘れがちなタグのNameを設定できる コード化することで、以下のように「あのサーバの設定なんだっけ、どこで設定してたっけ」のような無駄な時間がなくなり、 リソースの管理や開発の効率が高まります 。 resource "aws_instance" "test-server-01-example-co-jp" { ami = "ami-xxxxxx" availability_zone = "ap-northeast-1a" ebs_optimized = true instance_type = "t3.small" monitoring = true key_name = "key-pair-name" subnet_id = aws_subnet.id vpc_security_group_ids = [aws_security_group.test-server-sg.id] private_ip = "10.10.1.5" root_block_device { volume_type = "gp3" volume_size = 100 delete_on_termination = true tags = { Name = "test-server-01.example.co.jp" } } tags = { "Name" = "test-server-01.example.co.jp" } } リソースをコード化するメリットって？ リソースをコード化してgitなどでバージョン管理すれば、 レビューで認識齟齬がないことを確認しやすい 同一リソース・別環境の複製（test、staging環境など）が容易 コミットログから過去の変更時期や意図を確認しやすい ブラウザでの操作のように、設定変更ページを探す必要がない 一時的に手動で変更した設定の戻し忘れに気付きやすい（手動変更するなという話ですが） など、メリットがたくさんあります。 AnsibleやChef、Puppetとの違い IaCの文脈で同列に語られがちなAnsible・Chef・Puppetは、 サーバの「中」の設定をコード化するツール になります。 たとえば、OSユーザーの追加だったり失敗すると怖いsudoersとかだったり、Nginxや各種 ミドルウェア などのインストールなどがコード化できます。 Terraformは、サーバそのものや、ネットワーク、ストレージなどの サーバの「外」をコード化するツール なので、TerraformとAnsible等を上手く使い分けることで、環境構築や既存環境の改修がとても楽になります。 ※ Terraformでも、起動時のテンプレートを設定できたりしますが、Ansible等の方が柔軟性が高く使い勝手がいいです。餅は餅屋。 Terraformの使い方 公式サイト からダウンロードして、 GetStarted するだけ。 yum install(apt install)したことがあるなら一瞬です。 ※ 結構バージョンアップが早く、それによる破壊的な変更があったりするので、バージョンや更新情報に気を使う必要はあります。 よく使う、基本的なTerraformコマンドの一部を紹介します。 基本的にはこの2つ「plan」「apply」 一番使うコマンドは、きっと terraform plan だと思います。 コードを編集して、意図した変更になるかを確認するときに使います。 plan で確認した後、実際反映するのは terraform apply コマンドになります。 applyコマンドで 意図せぬ変更をしてしまうと戻せない（作り直す必要がある）場合もある ので、必ずterraform planコマンドを打って確認する必要があります。 既存リソースをTerraform管理する「import」 既存のリソースをTerraformで管理する場合に必要になるのが、 terraform import コマンドです。 たとえば、さきほど紹介したコード化したEC2が存在していて、Terraform管理されていない場合、そのままapplyコマンドを実行すると、その設定のEC2を新規作成しようとします。 importコマンドを実行することでコードとリソースが紐づき、Terraform管理できます。 $ terraform import aws_instance.test-server-01-example-co-jp i-xxxxxxxxxx(インスタンスID) なにをTerraform管理しているかを確認する「state list」 管理するリソースが増えてくると、今Terraformで何を管理しているのかを一覧で見たいタイミングも出てくると思います。 そういったときに、 terraform state list コマンドを使うことで一覧出力できます。 grep で特定のタイプのリソースに絞ったり、全体を俯瞰するときに便利です。 $ terraform state list aws_instance.test-server-01-example-co-jp aws_security_group_rule.test-server-sg aws_vpc.test-01-vpc ... ... Terraformの3大便利ツール Terraformを使い始めて1年ぐらいたち、いろいろ便利なツールも見つけたのでまとめて紹介します。 1. 既存環境を楽にTerraform管理する「Terraformer」 先ほどEC2をコード化しましたが、あれを全部手書きするのはあまり現実的ではありません。 既存リソースをコード化するなら、 Google （ GCP ）が開発する Terraformer というツールを使うのが便利です。 以下のようにコマンドを実行すると、既存リソースからコードを作成してくれるので、ほとんど自分でコードを書く必要がありません。 $ terraformer import aws --resources=ec2_instance ... # いろいろ作成される $ ls generated/aws/ec2_instance/ instance.tf outputs.tf provider.tf terraform.tfstate $ cd generated/aws/ec2_instance/ $ terraform init $ terraform plan ※ ↑のように、作成された ディレクト リに移動してTerraform planを実行すると、コード通りのEC2を作成しようとします。 先述した「terraform import」でコードとリソースを紐づけることで、既存のリソースをTerraform管理できます。 2. GUI でTerraformコードを生成できる「former2」 Terraformerは cli での操作なので、慣れない人は使いにくいかもしれません。 そういう方には、 GUI で既存リソースをコード化できる「former2」がおすすめです。 以下の画像のようにリソースを選択でき、Generateボタンを押すだけでまとめてコードを作成できます。 （作成後のコードは載せませんが、↑で書いたようなコードが自動で作成されます） former2.com ブラウザにcredentialsを登録することで、ボタンポチポチで欲しいリソースをコード化できます。 安全性が気になるところですが、 AWS 公式ブログでも以下のように紹介されています。 Former2 is designed never to send these credentials to an external server that isn’t an AWS API endpoint. 　 引用元： Accelerate infrastructure as code development with open source Former2 ブラウザにcredentialsを登録することに抵抗がある方（ほとんどの人はあると思いますが）は、docker-composeでローカルにホストする方法もあるので、検討してみる価値はあると思います。 dev.classmethod.jp 3. profile変更が楽になる「direnv」 複数サービスのTerraformを管理していると、確認のために実行した aws cli コマンドでprofileの切り替えを忘れて、別のサービスのprofileのまま実行してしまうことがあると思います。 direnvを使うことで、 ディレクト リと AWS PROFILEを紐づけられます。 これにより、 ディレクト リを移動するだけでPROFILEを切り替える ことができ、PROFILEの切り替え忘れを防げます。 github.com 実際に試してみます。 （※ 設定方法は上記の github を参照してください） たとえば、以下のように、複数サービスを管理しているとします。 works ├── serviceA │   └── .envrc └── serviceB ├── .envrc └── .envrc_prod 以下は実際に操作した画面になります。 ※ 前提: direnvを使って、各サービスの ディレクト リで.envrcを作成していること ①　serviceA ディレクト リに移動すると、serviceA/.envrcが自動で読み込まれて、 AWS_PROFILE=serviceA-test がセットされます。 ②　そこからserviceBに移動すると、serviceB/.envrcが読み込まれ、 AWS_PROFILE=serviceB-test がセットされます。 ③　また、serviceB/.envrc_prodのような本番用のPROFILEファイルを作成し、sourceで明示的に読み込めば、本番用の AWS_PROFILE=serviceB-prod に切り替わります。 基本的にはtest用PROFILE、必要なときのみ本番用PROFILEを読み込む、といった使い方ができて便利です。 （promptが設定されてると、本番系（ -prod など）のPROFILE名だと色が変わって、すぐにわかるのもありがたいです） ④　direnvで設定されていない ディレクト リに移動すると、 環境変数 がunsetされるのも安心です。 まとめ Terraformと便利ツールについてまとめてみました。 Terraformを使いこなせれば、リソースの管理がとても楽になるので、まだの方はぜひ試してみてください。 もっと体系的に学びたい、という場合は、以下の書籍がおすすめです。 実践Terraform AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）) | 野村 友規 | 工学 | Kindleストア | Amazon エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは。 ラク ス技術広報のLandh6です。 今回は、就職活動の上でも社員にとっても重要な、 ラク スの「福利厚生」についてご紹介します！ 昨今、 ワークライフバランス やワークスタイルを重視する傾向もあるように思います。 社員が安心して働ける環境、心身の健康、モチベーションやパフォーマンスを維持するうえでも大切な要素の一つです。 ここでは福利厚生を分類、列挙しながら、 ラク スにどのような「福利厚生」があるのか見ていこうと思います。 福利厚生とは 福利厚生は大きく分けると2種類 ラクスの福利厚生紹介 通勤関連 交通費支給 特別休暇関連 入社日に有給付与　 シックリーブ　 慶弔休暇　 ライフサポート ドリンク/スナック/ランチサポート お弁当の注文 ラクスマイル制度 マンスリーシフト タイムリーシフト制度　 家族手当 ベビーシッター補助制度 資格取得サポート 書籍購入・貸出サポート 財産形成 従業員持株会 文化・レクリエーション関連 サークル活動補助 コミュニケーションサポート 社員総会 終わりに 福利厚生とは 福利厚生とは、企業が労使関係の安定などの効果を期待して、任意あるいは法的に従業員に提供する諸施策のことです。 従業員やその家族の福祉のために、行われている取り組みを指します。 福利厚生は大きく分けると2種類 法定福利厚生 ……法律によって実施が義務付けられている福利厚生 例えば…健康保険／厚生年金／ 介護保険 ／労働保険　など ※必ず導入する必要があります。 法定外福利厚生 ……法律では義務化されておらず、企業が任意で制定している福利厚生 例えば…住宅関連／慶弔関係／医療・健康／ライフサポート　等 ※各企業が自由に設定することが可能なので、法定外福利厚生の種類は多岐にわたります。 ちなみに、福利厚生の対象者は、全ての従業員です。 （2020年4月1日に改正・施行「パートタイム・有期雇用労働法」「労働者派遣法」） ラク スの福利厚生紹介 ということで、ここでは健康保険／厚生年金／ 介護保険 ／労働保険等の「法定福利厚生」ではなく、各企業が自由に設定することができる「法定外福利厚生」をご紹介していきます！ ラク ス従業員の働きやすさを高めるため、ここ数年どんどん改正されており、今後もよりよい福利厚生にかかる制度の拡充をしていきます。 通勤関連 交通費支給 上限10万円／月 特別休暇関連 ラク スでは、完全 週休二日制 （土・日）となっており、その他祝日、年末年始休暇、夏季休暇があります。 有給休暇消化率は、80％を超えている状態です。 入社日に有給付与　 入社と同時に15日の有給休暇が付与される制度です。 シックリーブ　 本人や家族が私傷病となった場合最大、5日間の休暇を付与する制度です。 これにより、私傷病への不安のために 年次有給休暇 を一定日数残すことなく計画的な取得を促進します。 慶弔休暇　 例：結婚時7日間の休暇付与する制度です。 ライフサポート ドリンク/スナック/ランチサポート リフレッシュをしたいとき、コーヒーや紅茶など約20種類のドリンクを無料で飲むことができます。 また、低価格で購入できるスナックコーナーや、昼食の弁当注文サービスなどがあり、社員に好評です。 お弁当の注文 日替わり弁当を購入することができます。 当日の朝に注文ができるため、その日の気分でお弁当を選ぶことができます。 ※東京のみ ラク スマイル制度 子育て世代のための選択型就労制度です。 保育園の送り迎えに合わせて出勤・退勤時刻を前後にずらしたり、評価基準を時短勤務に合わせたスタイルに変更するなど、 ワークライフバランス に合わせた柔軟な働き方が実現できます。 マンスリーシフト 「1ヶ月単位」で始業時間を選択できる制度です。 始業時刻を8時から10時まで（30分単位5パターン）選択可能です。 タ イムリ ーシフト制度　 「１日単位」で始業時間を変更できる制度です。 各自の始業時刻の前後最大1時間（30分単位5パターン）で変更可能です。 家族手当 18歳未満の子どもの人数に応じて支給されます。 子1人3万円／月 子2人5万円／月 子3人6万円／月 ※役職者を除く ベビーシッター補助制度 小学校3年生までのお子様がいる社員を対象に、ベビーシッター利用時に割引が受けられる制度です。 資格取得サポート 業務上必要となる資格を取得する際には、受験費用を会社が補助します。 ※事前承認が必要です。 書籍購入・貸出サポート 業務上必要となる書籍の購入や、社内にある書籍の貸し出しをします。 ※事前承認が必要です。 財産形成 従業員持株会 持株会を通じて自社株を定期的に購入することで社員の資産形成をサポートします。 自社株購入時には奨励金を支給します。 文化・レクリエーション関連 サークル活動補助 ラク ス社員によるサークル活動がさかんに行われています。 サークル活動は、 ワークライフバランス の充実や、社員同士の信頼関係の構築に役立っています。 現在は、20を超えるサークルが各拠点で活動中です。 コミュニケーションサポート 社員同士のコミュニケーションを活性化させて業務の円滑化を図ることを目的に、懇親会費用の補助を行っています。 社員総会 会社全体の動向を知る機会として、各事業の総括や今後のビジョン、戦略などを全社員に共有する場を年に一度設けています。社長賞などの社員表彰も行われます。 終わりに いかがでしたでしょうか？ ラク スの福利厚生は、今回挙げたもの以外にも、状況に応じて随時更新されている最中です！ 少しでも興味持っていただけましたら、カジュアル面談等も実施しておりますので、ぜひ福利厚生について直接社員に聞いてみてください！ 最後までお読みいただきありがとうございました！ ◆ 関連ブログ - ラクスのSaaSプロダクト紹介【12種類まとめ】 - 【株式会社ラクス】SaaSプロダクト別の技術スタックを一挙公開！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

初めまして。QA担当のBell_Treeです。 今回は ウォーターフォール モデルについて実体験も交えて説明しようと思います。 はじめに ウォーターフォールモデルとは ウォーターフォールとアジャイルの違い アジャイル開発とは ウォーターフォールとアジャイルの違い ①スケジュール管理のしやすさ ②仕様の柔軟性 ウォーターフォール開発の実体験談 どのような流れでやっていたか 実際の経験を通して 自社サービスと請負案件の違い まとめ はじめに 本記事では ウォーターフォール モデルについて、実体験を交えて説明させていただきます。 あくまで私個人の体験になりますので、全部が全部こういったものではないということはご理解いただけますと幸いです。 ウォーターフォール モデルとは ウォーターフォール モデルについて、簡単に説明させていただきます！ ウォーターフォール の開発作業工程は以下の通りです。 1.要求定義（要求仕様） 　　↓ 2.外部設計（概要設計） 　　↓ 3.内部設計（詳細設計） 　　↓ 4.開発（プログラミング） 　　↓ 5.テスト 　　↓ 6.運用 上記のように各工程を1から順番に上から下へと流れていく様子が"滝"のようであることから、 " ウォーターフォール "と呼ばれています。 ウォーターフォール は基本的に工程を飛ばして開発を進めることはなく、各工程きっちり段階を踏んで次の工程へと進んでいきます。 仕様の考慮漏れなどイレギュラーな事態がない限りは、前の段階へ戻ることはありません。 ウォーターフォール と アジャイル の違い アジャイル 開発とは アジャイルソフトウェア開発 - Wikipedia より一部引用させていただきますと、 アジャイル ソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である（ アジャイル ソフトウェア開発宣言）。 すなわち自己組織的なチームが対話の中で方向性・仮説を見出し、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。 というような説明がされています。 もう少しざっくり説明すると・・・ 『ユーザーストーリー単位で仕様の調整や実装、テストの実施を柔軟に行っていく開発手法』 になります。 ウォーターフォール と アジャイル の違い ①スケジュール管理のしやすさ ◆ ウォーターフォール ウォーターフォール は、おおよその工程や納期などが決まっているので、納期に合わせてどの工程がいつまでに終わって、この工程はいつまでに始めないと！のような予定が立てやすいのが特徴です。 ◆ アジャイル 開発単位が小さく柔軟に対応できる反面、試行錯誤を繰り返して行うこともあるため、スケジュール管理が難しい部分があります。 ただし、 トレードオフ スライダーにより「品質」「予算」「納期」「スコープ」の優先順位が定まっている場合は、「スコープを調整することによりスケジュール遅延を発生させない」等、定めた指針によって関係者で擦り合わせを行うことができます。 ②仕様の柔軟性 ◆ ウォーターフォール どのような製品にしたいか？ 仕様を上流工程の段階で決め、その仕様に則って開発を進めていきます。 そのため、決められた仕様での開発となるため、柔軟性には欠けます。 ◆ アジャイル ある程度の仕様が定まっている状態でも、開発途中などに「やっぱりこっちの方がいいんじゃない？」のような意見があった場合に、より良い方に転換できる柔軟さがあります。 ただし、仕様がコロコロ変わることでドキュメントの最終着地点が曖昧になりやすい面もあります。 【イメージしてみよう】 脈絡もなく、 ウォーターフォール と アジャイル の違いをガ〇ダムのプラモデルで例えてみようと思います。 　　　　　　　　　　　 例えばですが、A君がガ〇ダムのプラモデルを買ったとします。 決められた仕様(=設計書)に沿って組み立てていけば、仕様通りの製品ができあがりますよね？ つまり、 ウォーターフォール ガ〇ダムの完成です！ 話は変わり、B君、C君、D君によるプラモデル同好会にE君より「こういうコンセプトのガ〇プラを作成して欲しい」と依頼がありました。 B君、C君、D君はコンセプトを基にどのようにしたらクライアントであるE君が満足するか話し合いました。 また、逐一E君に作業進捗を報告し、試作物を見せ、E君からは「こういうのもかっこいいけど、こういう風にしたらよりかっこいいかも！」と意見を貰ったりしました。 そうやって、試行錯誤を繰り返しE君が納得のいく物を作成しました。 「ガ〇プラは自由だ！」と言わんばかりのオリジナルガ〇プラ、 アジャイル ガ〇ダムの完成です！ ...イメージできましたでしょうか？(笑) 上記のように決められた仕様で作成するものが ウォーターフォール っぽく、よりこっちの方がかっこいいのではと仕様を変更したりできるのが アジャイル っぽいということを"仕様の柔軟性"の部分に絞ってお伝えしたかったです。 ...というのと、私がただただガ〇プラで例えられないかなと思い付きで書いた次第ですので、超個人的な解釈となります！ ◆ 関連ブログ ・ 【アジャイル開発とは】ウォーターフォールとの比較・スクラムから見えてくるもの ウォーターフォール 開発の実体験談 ここからは私が前職で実際に体験してきた ウォーターフォール での開発ってどういう感じなの？ などを記載していきたいと思います。 私は前々職で ウォーターフォール 開発を7年、前職で スクラム 開発を2年ほど経験してきました。 今回は前々職での経験を基に記載させていただきます。 どのような流れでやっていたか 主に受託業務を行っている会社に勤めていたため、大まかに下記のような流れでやっていました。 ※記憶が少し曖昧なので、本当に大まかなものとなっております。 ①営業さんから開発チームに見積もりや資料作成の依頼あり→顧客に提出 　　　　　　　　　　　　↓ ②案件受注 　　　　　　　　　　　　↓ ③顧客に納品時期確認、見積もりとも照らし合わせながら大まかな WBS を作成 　※要件定義次第では想定外の内容が飛び出してくることもあるので、 WBS のFixは④の後などに設定 　　　　　　　　　　　　↓ ④顧客と要件定義の MTG を何度か実施し、要件を固める 　　　　　　　　　　　　↓ ⑤要件定義書を基に設計書を作成 　　　　　　　　　　　　↓ ⑥設計書を基に開発( 単体テスト 含む)、テスト仕様書を作成 　　　　　　　　　　　　↓ ⑦ 結合テスト を実施→不具合が出たら修正／修正確認 　　　　　　　　　　　　↓ ⑧顧客側にて受入試験→不具合が出たら修正／修正確認 　　　　　　　　　　　　↓ ⑨顧客OKが出たら、必要なドキュメント類をまとめ納品 　　　　　　　　　　　　↓ ⑩(話があれば)運用保守 実際の経験を通して 【スケジュールについて】 スケジュールを組み、その通りにタスクをこなしていけば、基本的には平和に終われるのが ウォーターフォール の良いところです。しかし、そう簡単には上手くいかない場合もあります... 例えば、機能の実装フェーズにおいて機能の実装が難航した場合にスケジュールに遅れが発生するとします。 そうなると、 結合テスト のフェーズにツケがまわってくるので、かなりせかせかとテスト実施をしないといけないという状況がありました。 また、設計書を基に試験仕様書を作成していたのですが、確認しないといけない項目のボリュームが大きくなり、想定以上の 工数 を要することもありました。 そういった場合は、早めに増員願いをマネージャーなどに相談して対応しておりました。 学びとしては納期はきっちり意識しつつも、余裕をもったスケジュールを組み立てることが大事ですし、アラートは早めにあげられるに越したことはないと思いました。 バッファはなんぼあってもいいですからね(笑) 【要件定義段階にて】 おおよそ、要件定義前の見積もり時に顧客が実現したいことなどの資料があったのですが、要件定義を進めていくうちに新しい情報が出たり、そもそもの実現したいことの難易度が変わったりというのが割とありました。 そのため、要件定義が終わる段階で完全に要件がFixしたら再度見積もりをするのが吉です。 また、スケジュールに関しても大幅に修正が必要な場合は顧客に明確な理由を伝え、リスケすべきです。 でないと、実際に作業が始まった際に地獄がじわじわと広がっていきます...(笑) 自社サービスと請負案件の違い 一つ目は、無理のないスケジュールとなっていることです。 私は弊社の某サービスに関わっているのですが、弊社に入社して実際にリリースまでの流れに携わっての感想が「スケジュールに余裕があるから大変と感じない」というものでした。 ※私個人のタスク量からの個人の感想となります。 ※後述とはなってしまいましたが、私が現在携わっている某サービスは ウォーターフォール モデルにて開発を行っております。 また、作業内容も決まっているため、それに沿って作業を進めていけば、毎回大幅にぶれるということがありません。 二つ目は、融通が利きやすいと思います。 自社サービスですので新規バグではない既存バグが発見された場合、顧客影響が低いものであれば今回リリースするバージョンでは修正せず、後続のバージョンで修正することができるのが請負案件との違いだと思います。 基本的に上流工程での内部調整となりますので、自社内で完結できるのは自社サービスでの開発のメリットかと思います。 まとめ ここまで読んでいただきありがとうございます。 今回は私の経験も交えて、 ウォーターフォール について記述させて頂きました。 大まかに ウォーターフォール がどのようなものなのかを、イメージできるものになっていれば幸いです！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

技術広報の飯野です。 ラク スでは今年4月に11名のエンジニアが新卒入社しました。 入社後2ヶ月半は講師のもとで研修を行い、研修を経た後に配属となります。（今年度の研修はオフラインでの開催となりました！） 6/28に研修の集大成となる「技術研修発表会」が行われましたので、本投稿にて紹介させていただきます。 21新卒が執筆した昨年度の研修内容もよろしければ合わせてご覧ください！ - 【2021年】ラクスの新卒エンジニアが新卒研修を振り返ってみた 目次 研修概要 成果発表会 まとめ 研修概要 研修は2022/4/13〜6/28の51日間行われました。 技術基礎研修 サーバーサイド Java Spring boot Thymeleaf フロントエンド HTML CSS JavaScript jQuery Ajax といった技術を通じてWebアプリケーションの構築方法を学習しました。 また、 Linux 、DB、コンピューター、ネットワークの基礎用語、テストの手法等もカリキュラムに組み込まれています。 実務演習 研修で学んだ内容を、個人課題を通してアウトプットしていきます。 確認テスト 毎朝の小テスト、 定期テスト で理解度のチェックを行います。 プロジェクト型研修 ECサイト の構築をチーム開発で行います。（開発期間は6/17〜6/28の8日間） チームでは「必ず一人が一つの役割を持つ」というルールのもと、全員が何かしらのリーダーを担っています。 期間内に作成する機能は以下3つに分類されています。 基本機能 全チーム必ず実装する機能 追加機能 必須ではないが余裕があれば実装してほしい機能 独自機能 他チームとの差別化を図るチーム独自の機能 そして、開発期間終了後に成果発表会として各チーム20分ずつのプレゼンを行いました。 成果発表会 Aチーム、Bチーム、Cチームの3チームに分かれグループ演習が実践されました。 Aチーム まず、Aチームからは「 ラク ラク アロハ 」と名付けた飲食店の ECサイト の発表です。 コンセプト お客様を楽にする お店側も使いやすい を掲げ「両者の要望を叶えられるようなプロダクト」を目指し開発を行いました。 独自機能 お客様視点 購入時にログイン情報からお客様情報を取得してくる（入力のコストを無くす） ショッピングカートアイコンにアイテム数を表示 お店視点 レコメンド機能 管理者機能 基本機能としては存在していなかったが、両者が使いやすいコンセプトを掲げたことで、お店視点の機能を作成 等、コンセプト通りにユーザーがより使いやすい機能が独自に実装されていました。 よかった点 開発初期にコンセプトを決定したことで指針ができ、認識を揃えて開発を進めることができた タスク管理ツールにTrelloを導入し、追加機能がすべて実装できた 1時間半に1回現状報告をする等、困ったことがあったらすぐに共有できる体制にした 反省点 HTMLのフォーマッターを統一しておらず、push時に差分が大量に出てしまった 仕様の確認不足により変更作業が増加してしまった 上記2点のにより、大量のコンフリクトと、他の人の修正に気づかず デグレ を発生させてしまった 質疑応答 「お店側の視点」というア イデア はどうやって出た？ まずお店側に使ってもらえないとお客様も使ってもらえないので、お店にも重きを置いた 最初のコンセプト決めの時点でチームで話題に上がった タスクの優先順位はどう決めた？ 基本機能＞追加機能＞独自機能の順番に進めた 簡単な機能順にタスクを並べ、上から順に実装した 技術的に攻めた箇所はどこ？ 強いて言うならデザイン モバイルでも使いやすいようにレスポンシブを取り入れたり デザインはどうやって決めた？ ユーザーにコストがかからないように 「テーマ＝アロハ」なのでテーマカラーを水色にする等、利用者が違和感を抱かないように エディタは人によって変えていた？ チームで統一していたが、フロントエンドは VSCode 、バックエンドは STS を採用した Bチーム 続いて、Bチームからは「 ラク ラク coffee 」と名付けたカフェの ECサイト の発表です。 コンセプト お客様視点：欲しい商品がすぐに見つかる ECサイト お店視点　：商品が売れやすい ECサイト を掲げ、こちらもAチームと同様に ECサイト を利用するお客様と、商品を販売するお店の双方を視点に開発が行われました。 独自機能 レビュー機能 注文履歴から商品を5段階で評価できる機能 レコメンド機能 「 協調フィルタリング 」 アルゴリズム を利用し、嗜好の類似しているユーザーに対しパーソナライズされた商品を提示 管理者側分析機能 年代別の売上グラフを表示できる等、商品毎の売上が分析できるようデータを可視化 上記の機能を実装するにあたり大量のデータが必要になり、テストデータの自動生成処理も実装するという独自性も見られました。 ふりかえり トラブルなく開発が行えた 各個人が少し上のレベルのタスクに挑戦できた クラス図の理解を丁寧に行い、基本機能の実装が早く終わった 進捗管理 ツールをうまく活かせなかった 改善点 デフォルトのデザインを使用していたので、独自性を出したい レビュー機能 を管理者分析機能にも活かしたい UX 質疑応答 協調フィルタリング は自分でコードを書いている？ Java で独自で実装している レコメンド機能の改善点はどういったところ？ データの分母が少ないとレコメンドがうまくいかない よって、お店側の商品をカテゴライズすればもっとレコメンドがうまくいくはず これまでに大量データを扱ったような経験があった？どういった経緯で アルゴリズム を利用した？ 大学院でAIを使用していた経緯がある、データを見るのが好きだったことも影響しているかも 他チームは4人だが、人数が少ないハンデはあった？ とにかく機能を実装しきるのを目標に頑張った、デザインは後回しになって手が回らなかった できるだけバグを生まないように、開発の指針を初めに決めておいたことで3人でもここまで実装できたと思う Cチーム 最後に、Cチームからはおもちゃの ECサイト の発表です。 コンセプト まず、おもちゃを購入する客層を分類し「孫を持つシニア世代」にターゲットを絞ることに。 ECサイト に馴染みのあるターゲットは既存サイトを使うはず シニア世代にとって、既存の ECサイト は機能が多く使いづらいのではないか？ 販売する側もシニア世代に向けた ECサイト を想定していないのではないか？ という仮説からシニア世代にとって使いやすく、あらゆる問題を解決に導く「 ラク ラク トイ 」を開発することに決定しました。 独自機能 LINEでのOAuth2認証 商品の絞り込み機能 性別や年齢、予算を入力することでターゲティングされた商品が表示される RESTAPIで実装し、SPAでの表示を可能に また、商品購入フローをヘッダーに表示する等、ターゲットに向け使いやすさを意識したこだわりが見られました。 まとめ コンセプトを明確にしたことで、どういった機能が必要か全員が指針を持って開発が行えた ただ、コンセプト設定に時間がかかり他チームとの進捗の差に焦って開発を急いでしまった 上記によりレビューが甘くなり、終盤に大量のバグが発生 技術だけでなく技術以外でも未熟さを痛感したチーム開発だった 質疑応答 SPAのように作るにあたって（フロントエンドとバックエンドの繋ぎこみで）苦労したことは？ フロント側でインタフェースを決めて、フロント側でとにかく頑張ったw ターゲティングが凄い、が、シニア層的には文字が小さい（笑）、文字サイズを選べたりするとよりよい 対象年齢の絞り込みは、どのように実装している？ 商品テーブルに対象年齢を持っており、インプットの範囲のデータを表示している 総評 講師より 研修期間中、全員が努力していて、積極的に学ぶ姿勢がありました。 全員が能動的で、学習意欲も高く、定期的なテストの点数も例年と比較し非常に高い結果となりました。 最後のチーム演習では、最初にコンセプトを決めそのコンセプトに沿って機能を考え、スケジュールを立てて開発を行う進め方をしていたチームが多かったです。 そのため、8日間では間に合わないと思われるような機能開発にも着手していました。それもよい経験だったと思います。 また、研修で使用していない技術もふんだんに使用していました。 講師に対してのみならず、同期に対しても気遣い、挨拶ができ、個々のレビューに対してもお礼が言えるといったような、技術だけでなくヒューマンスキルの部分も素晴らしかったです。 総じてレベルの高い形で研修を終えることができたと思います。 とは言え、今回学んだ技術はまだまだ氷山の一角なので、今後も継続した努力に期待しています。 配属先でも間違いなく活躍できると思うので、今回の研修を糧に頑張ってください。 東京開発統括部　統括部長：間澤より 皆さんお疲れ様でした。研修楽しかったですか？ 開発は楽しいものです。 開発に限らず、できないことができるようになる経験って楽しいですよね。 仕事もそうです。 ラク スは国内 SaaS のトップを走っている企業です。 たくさんの製品を扱っているのでその楽しさももちろんあるけど、責任もあります。 責任があるからこそ、刺激的な楽しみもあります。 不具合が起きたらめちゃくちゃ焦るけど、皆さんなら絶対に乗り越えられます。 チームで協力することで、楽しく利益を獲得して品質の高いサービスを作っていきましょう。 今回の研修でも、AチームとCチームはコンセプトがしっかりしていて ユーザビリティ が高いサービス、Bチームは技術に特化したりと、それぞれが強みを活かしてよいサービスを生み出しました。 皆さんの力を合わせるとよりよいものが作れるという経験が研修を通して実感できたと思います。 その楽しさを忘れずに、配属先でも頑張ってください。期待しています。 開発本部 本部長：公手より 発表とてもよかったです。 ユーザビリティ 、技術、ターゲットを絞り切る等、各チームの方向性が見られました。 特に、ビジネスはターゲットを絞るのが大事なので、新卒でそういった視野が持てているのは衝撃でした。 今日皆さんに伝えたいことは2点あります。 まず1点目。 エンジニアは積み重ねの職業、日々学習し続けるのが宿命付けられているもの、と思ってください。 業務時間だけコードを書いていれば優れたエンジニアになれるわけではありません。 ラク スのトップエンジニアも、若い頃からも、今も、常に勉強しています。 とは言え、プライベートももちろん大事なので、バランスが大事。 最初は難しいと思うけど、だんだんうまくなっていきます。ぜひ皆さんにも身につけて欲しいです。 次に、2点目。 開発はチームで行うもの。それを忘れないでいてほしいです。 今後楽しいこともたくさんあるけど、苦しいこともたくさんあると思います。 ただ、苦しいことも仲間がいれば必ず乗り切れるので、周りを頼ってチームに相談してほしいです。 管理職も若い頃は、皆さんと同じ。苦しみながらいろいろ乗り越えてきて今があります。 皆さんが今後苦しむであろうことは大体経験しているはずなので、気軽に相談してほしいです。 最後に、僕がずっと言い続けている『楽しい職場を作る』を、ぜひ皆で実現させましょう。 まとめ 新卒エンジニアの成果発表会の様子をまとめさせていただきました。 わたしも実際に発表を見学しましたが、コンセプト決め〜デザイン、実装までの工程を僅か8日間で行ったとはにわかに信じられないほどクオリティの高いWebアプリケーションとなっていました。 コンセプト、独自機能、デザイン、発表内容それぞれにチームのカラーがあり、チームが「掛け算」であることを実体験として感じられたことと思います。 今回の経験を活かし、配属先でもチーム力を活かしてぜひ活躍していってほしいです。 また、新卒で入った会社の同期は 一生物 だと思うので、お互いに切磋琢磨しながら高め合ってくれることを期待しています！ 最後までお読みいただきありがとうございました。 引き続き、 ラク スをよろしくお願いいたします！ エンジニア新卒採用サイト https://fresh-recruit.rakus.co.jp/ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com