こんにちは、CRE部 技術支援チームです。
ニフクラDevOps with GitLabはDevOpsに必要な環境を簡単に構築できるサービスです。
インターネット接続でDevOpsサーバー作成後すぐにDevOps環境を利用できます。
しかし、セキュリティの観点からグローバルネットワーク経由でDevOps環境にアクセスしたくない場合があります。
そのためセキュアにDevOps環境にアクセスする構成検証を紹介します。
構成検証として以下のニフクラクラウドデザインパターンの2パターンが考えられます。
今回は拠点間VPNゲートウェイを使ってニフクラDevOps with GitLabをプライベートLAN構成で構築します。
こんにちは、CRE部 技術支援チームです。
ニフクラのロードバランサー（L4）、マルチロードバランサーは、様々な場面でご活用いただいており、サーバー冗長化、可用性の向上、負荷分散等に欠かせないコンポーネントです。
そんなロードバランサーですが、どれくらいのスペックで構築を進めたらよいか、悩まれたことはないでしょうか？（ロードバランサーに限った話ではないですが。。）
オンプレミス環境からの移行であれば、既存環境のトラフィックや負荷状況を把握でき、新環境でのサイジングに活かすことができますが、新規サービス立ち上げ等なかなか推測の難しいケースがあります。
最初からスペック不足だとサービスの利用に支障が出てしまいますので、たいていのお客様は、余裕を持ったスペックを選定しますが、高いスペックのものを用意することは当然のことながらコストが高くなるというデメリットにつながります。
ニフクラのロードバランサーは、「最大ネットワーク流量」でスペックを選択し、その流量で料金が変動します。流量に関しては注意点があり、契約している最大ネットワーク流量を超過した際、設定した流量を超えた通信はドロップされる可能性があります。これはロードバランサーがボトルネックになってしまうことを意味します。なるべくコストは抑えつつ、ボトルネックとならないような仕組みを実装できれば課題が解決できそうです。
今回は、これらのような課題を解決するための方法として、ニフクラスクリプトを活用したマルチロードバランサーの自動スケールアップをテーマに、省コストかつ安定運用ができるか、検証してみたいと思います。
こんにちは、CRE部 技術支援チームです。
前回、前々回に引き続き「ニフクラにおけるDevOps開発作業」についての記事の最終回になります。
今回はGitLabのマージリクエスト機能(他社サイトへのリンクです)を使って、実際の開発現場を想定したエンハンス開発作業を実施して、実践的なDevOps開発を紹介します。
