今Serverlessが面白いわけ
プレゼンテーションスライド @ DevLOVE X 2019 Presentation Slides for Breakout session at DevLOVE X 2019 https://devlove.wixsite.com/devlovex
プレゼンテーションスライド @ DevLOVE X 2019 Presentation Slides for Breakout session at DevLOVE X 2019 https://devlove.wixsite.com/devlovex
Google、Dockerデーモンに依存せずコンテナイメージをビルドできる「kaniko」オープンソースで公開
Google、Dockerデーモンに依存せずコンテナイメージをビルドできる「kaniko」オープンソースで公開 通常、Dockerfileからコンテナイメージをビルドするには、Dockerデーモンにアクセスする必要があります。Dockerデーモンは実行にルート権限を必要とするため、ルート権限に簡単にアクセスできない環境、例えばKubernetesクラスタ内のDockerコンテナ環境などではコンテナイメージのビルドが難しいとされてきました。 オープンソースで公開されたツール「kaniko」は、この課題を解決するために開発されたとGoogleは説明しています。 With kaniko, we both build an image from a Dockerfile and push it to a registry. Since it doesn’t require any special
Kubernetesがクラウド界の「Linux」と呼ばれる2つの理由：これから始める企業のためのコンテナ実践講座（3）（1/3 ページ） 大量のコンテナ管理や負荷分散を実現する「Kubernetes」について概要から本番活用の仕方まで解説する「これから始める企業のためのコンテナ実践講座」第3回は、Kubernetesがクラウド界の「Linux」と呼ばれている理由とともに、Kubernetes内部の仕組み、機能を紹介します。
任天堂：新しい汎用ゲームサーバーを Google Kubernetes Engine、Cloud Spanner などを駆使して構築 | Google Cloud 公式ブログ
任天堂：新しい汎用ゲームサーバーを Google Kubernetes Engine、Cloud Spanner などを駆使して構築 世界中で愛好されている任天堂株式会社（以下、任天堂）の家庭用ゲーム機「Nintendo Switch」。そのオンライン マルチプレイを担う汎用ゲームサーバーの動作基盤に新たに Google Cloud が採用されました。多くのユーザーとの通信を処理しなければならないこの仕組みを、なぜ Google Cloud 上に構築したのか。どのような工夫を施すことで、安定性・可用性と運用負担の軽減を両立させたのか。構築に携わったエンジニアのお二人に話を伺いました。 利用しているサービス： Google Kubernetes Engine、Agones、Anthos Service Mesh、Cloud Spanner、Cloud Load Balancing、Cloud
AWS Startup ブログ スタートアップのためのコンテナ入門 – Kubernetes 編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 「スタートアップのためのコンテナ入門 – 導入編」「スタートアップためのコンテナ入門 – AWS Fargate 編」という記事を公開してきましたが、Kubernetes に興味があるスタートアップも多いのではないでしょうか。今回は Kubernetes にフォーカスしてお話しします。 なお Kubernetes 以前に、「そろそろコンテナやった方がいいか？」「なんとなく使い始めたけれどこれでいいのか？」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。 目次 Kub
はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ？」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基本的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基本です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub
クラウドのアーキテクチャ図作成ツール「CloudSkew」、Webブラウザから無料で利用可能。AWS／Azure／GCP／Kubernetes／Oracle Cloudなどマルチクラウド対応
クラウドのアーキテクチャ図作成ツール「CloudSkew」、Webブラウザから無料で利用可能。AWS／Azure／GCP／Kubernetes／Oracle Cloudなどマルチクラウド対応 クラウドのアーキテクチャ図を作成するためのWebアプリケーション「CloudSkew」が公開されています。 AWS／Azure／GCP／Kubernetes／Oracle Cloud／HashiCorp／Alibaba Cloudなど人気のクラウドやツールのアイコンがあらかじめ用意されており、Webアプリケーションとして提供されているためインストール不要で、誰でも無料で利用可能です。 操作は一般的なドローツールと同じように、左側からアイコンを選んで真ん中の図に置き、アイコン同士を矢印でつなげていくことでアーキテクチャ図が作成されていく、という感じです。 開発しているのは、元マイクロソフトのエンジニアを
GitLab.com、200TB超のデータとともにAzureからGCPへ移行完了。三度の計画停止による予行演習を繰り返し、移行手順も公開
GitLab.com、200TB超のデータとともにAzureからGCPへ移行完了。三度の計画停止による予行演習を繰り返し、移行手順も公開 ソースコード管理サービスを提供するGitLab.comは、GitHubの競合として見なされています。そのため、今年の6月にマイクロソフトがGitHubを買収するとの報道の際には、大手企業の傘下にない独立したGitサービスの提供元として突如として注目度が上昇していました。 参考：GitLabへのインポートが普段の10倍に急増、GitHubの買収報道で その同じ6月、GitLab.comはこれまで同社のサービスを提供する基盤として利用してきたMicrosoft Azureから、Google Cloud Platformへ移行することを発表します。 I wrote a post about @gitlab's project to migrate our SA
ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役
Infrastructure as Dataとは何か
最近GCPから登場したKubernetes YAMLのPackage managerであるKptは「Infrastructure as Data（Configuration as Data）」という考えかたを基礎としてそれを推し進めようとしている．それ以外にもKubernetesのEcosystemには（明示はされていなくても）この考え方が中心にある．Infrastructure as Codeとは何が違うのかなど歴史を振り返りつつまとめてみる． （指針はBorg, Omega, and Kubernetesという論文にあるが「Infrastrcuture as Data（Configuration as Data）」という言葉を明確に定義した文章はない．この記事はReferencesに挙げるいくつかのPodcastにおける@kelseyhightowerの発言や，それに反応する@bgra
Terraform, Dockerfile, KubernetesなどIaCの脆弱な設定をCI/CDで検知する - knqyf263's blog
概要 自分の所属企業であるAqua SecurityがTFsecというOSSを買収しました。 blog.aquasec.com TFsecはどういうツールかというとTerraformの静的解析スキャナーです。Terraformの設定ファイルを渡すことでセキュリティに関する設定ミスを主に検知してくれます。 github.com そのアナウンスに伴い、TFsecは自分が開発している脆弱性スキャナーであるTrivyに統合されました。TrivyではTerraformに加えDockerfileやKubernetesなど、いわゆるInfrastructure as Code（IaC）の設定ミスを検知するマネージドポリシーも提供しています。他にもJSONやYAMLなど一般的なファイルフォーマットに対応しているため自分でポリシーを書くことでそれらの検知にも使えます。CloudFormationやAnsib
Javaアプリケーションを自動的にDockerイメージにビルドしてくれる「Jib」、Googleがオープンソースで公開 － Publickey
Javaアプリケーションを自動的にDockerイメージにビルドしてくれる「Jib」、Googleがオープンソースで公開 Googleは、Javaアプリケーションを自動的にDockerコンテナ化するツール「Jib」をオープンソースで公開しました。 JavaのビルドツールであるMavenもしくはGradleのプラグインとしてJibをインストールすることで、Docker環境の構築やDockerfileなどを記述することなく、ビルドプロセスのなかで構成を読み取り、Dockerコンテナのイメージを生成、Dockerコンテナのレジストリへの登録まで自動的に行ってくれます。 これまでJavaアプリケーションをDockerコンテナ化するには、JavaアプリケーションをビルドしたうえでDocker環境を用意してDockerfileを記述し、そこでDockerイメージを生成するといった手順が必要でした。 Ji
4台のラズパイでk8sクラスタを組んだ
ラックについて 今回買ったラックは、なぜかネジを締めるとWIFIが繋がらなくなる事象が発生した。多分金属製だからと思われる。 面白いことに、手をラックの近くに置くとWIFIがつながる。（繋がらない場合もある） すべてのラズパイがWIFI接続というわけではなくmasterのみなのであんまり影響がないが、本事象は完全に想定外だったのでラック選びは要注意。 ラックの組み立て 説明書あったが、ネジの種類のラベルが貼っていなくて全然分からなかった。 ので、公式が動画を出しているのでこちらを参考に組み立てた。 なぜかネジが足りなかったり余ったりしているが、ガタガタしていないので一旦気にしない。 OSをSSDにインストール OSは「Ubuntu Server 22.04.2 LTS(64bit)」を使う。 歯車のところからWIFIやssh、キーボードレイアウトなど設定をよしなにやる。 Mac側の接続
メルカリ社内ドキュメントツールの Crowi を Kubernetes に載せ替えました | メルカリエンジニアリング
最近、SRE になった @b4b4r07 です。今回は、直近のタスクだった社内アプリを Kubernetes に載せ替えた話をします。 前置き メルカリでは全社的 1 に Crowi という Markdown で書ける Wiki アプリケーションをナレッジベースとして採用しています。 site.crowi.wiki 以前は、プロダクトチームは Qiita:Team、コーポレート系は Google Sites と言った具合に、各部署ごとに異なるドキュメントツールを使っていました。これではよくないと、エンジニアに限らず誰でも書きやすく参照しやすい Wiki のようなサービスが必要とされ、Crowi の採用に至りました。 まずはみんなに使ってもらうために広めていこうと、試験的に導入が始まったため、今回の移行話までは 1 台の EC2 インスタンスにアプリケーションサーバと Nginx、Mongo
Googleがオープンソースで公開したgVisorは、準仮想化のような仕組みを用いて従来のコンテナよりも安全性を高めたコンテナランタイムだ。Kubernetes時代の標準コンテナランタイムとなる有力候補かもしれない。 Dockerなどに代表されるコンテナ型仮想化は、OSのユーザー空間の名前空間を分離することなどで実現されています。 この仕組みの利点は、あらかじめ起動されているOSの上で名前空間を分離するだけでコンテナが起動できる点にあります。これがコンテナの迅速さや軽量さにつながっている一方、コンテナ間でOSのカーネルを共有しているためにコンテナ間の分離レベルは高くなく、同一OS上で稼働している別のコンテナの負荷の影響を受けやすかったり、コンテナからOSのシステムコールを直接呼び出せることなどによるセキュリティ上の課題を引き起こしやすくもあります。 OCIに準拠し、runc互換のgViso
Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開
Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開 Googleは分散アプリケーションの開発とデプロイを容易にするフレームワーク「Service Weaver」をオープンソースで公開しました。 Introducing Service Weaver! Service Weaver is an open source framework for building and deploying distributed applications. It allows you to write your application as a modular monolith and deploy as a set of microservices. Learn more → https://t.co/XmnVALYXNC pic
Dockerを管理するKubernetesの基本的な動作や仕組みとは？ Kubernetesを触ってみた。第20回 PaaS勉強会
Kubernetesは、数十から数百といったコンテナからなるアプリケーションのデプロイや管理、死活管理といった運用を支える機能を備えています。主な機能や仕組みを紹介します。 コンテナ型仮想化のDockerを管理するフレームワークとして、Googleがオープンソースとして公開したKubernetesが急速に注目を集めています。KubernetesのプロジェクトにはDocker本体はもちろん、マイクロソフトやレッドハット、IBM、VMwareなどが参加を表明しており、事実上の標準になりそうな勢いです。 Kubernetesはどのような機能を持ち、仕組みはどうなっているのか。有志により都内で開催された「第20回 PaaS勉強会」の草間一人氏のセッション「Kubernetesを触ってみた」の内容をダイジェストで紹介します。 NTTコミュニケーションズという会社で、Cloudn PaaSというClo
CloudNative Days Kansai 2019前夜祭のLTで発表した資料です。 発表の大筋は@makingの『Pack to the Future - SpringOne Platform 2019報告会』 https://docs.google.com/presentation/d/1rzaxReQ92WaWI24v-GsTwjtLCMq2YaFSTl9t6SEjPxQ/mobilepresent?slide=id.g6ad6e2f668_0_5 およびその元ネタの『Pack to the Future: Cloud-Native Buildpacks on k8s』 https://www.slideshare.net/SpringCentral/pack-to-the-future-cloudnative-buildpacks-on-k8s をベースにしています。 Clou
JAWS DAYS 2019 Aトラック https://jawsdays2019.jaws-ug.jp/session/1918/
今学ぶべき技術 by deeeet
今学ぶべき技術 by deeeet 会津春の大LT大会 26 May 2018 Taichi Nakashima About me @deeeet / @tcnksm (GitHub) https://deeeet.com Tech lead at Mercari microservices platform team (We're hiring!) 2 今学ぶべき技術 3 今学ぶべき技術 英語 4 英語かよ！引っ込め👎 学ぶべき技術は何かを知るには「英語」が必要 技術を深く学ぶには「英語」が必要 5 英語で学ぶべき技術を知る 6 そもそも 何を学ぶべきかは自分で知る必要がある 学ぶべき技術は個人の趣向によって異なる 学ぶべき技術は所属する組織や環境によって異なる 学ぶべき技術は立場によって異なる 7 英語で日々の情報収集をする 多くの技術トレンドやプラクティスは英語圏から現れる 日本語
コンテナとサーバ仮想化の違いと、Docker, Kubernetes, OpenShift - Speaker Deck
Transcript Red Hat K.K. All rights reserved. 1 コンテナとサーバ仮想化の違いと、 Docker, Kubernetes, OpenShift レッドハット株式会社 ソリューションアーキテクト 森若和雄 <kmoriwak@redhat.com> 2018-04-10 Red Hat K.K. All rights reserved. 2 もくじ サーバ仮想化とコンテナの違い • サーバ仮想化とコンテナ • コンテナの使いどころは ? • コンテナの注意が必要な点 Docker, Kubernetes, OpenShift • Docker は何をするのか ? • Docker は何がよかったのか ? • オーケストレーターとは ? Kubernetes とは ? • OCI (Open Container Initiative) とは
Kubernetes ベスト プラクティス 6 選
退屈な技術を選ぶことについて
この記事は、著者の許可を得て配信しています。 https://panelbear.com/blog/boring-tech/ 注：この記事で書かれている考え方は、過去に何度も取り上げられています。長年にわたって私の視点に大きな影響を与えてきた記事の一つに、McKinley氏の「Choose Boring Technology（退屈な技術を選ぶ）」というものがあります。以下では、私自身の経験からこのトピックを探り、最近のプロジェクトでKubernetesを使うことになった経緯を紹介します。 長年にわたり、私は多くのエンジニアが会社の成功や失敗の多くを技術的な選択が原因であると主張する傾向があるところを見てきました。私にももちろんそういう時もあります。それはしばしば正当化されますが、大多数のスタートアップ企業にとって、プログラミング言語、フレームワーク、あるいはデータベースの選択はそれほど重要
YouTubeがMySQLをスケールアウトする「Vitess」をオープンソースで公開。Kubernetesに対応
YouTubeがMySQLをスケールアウトする「Vitess」をオープンソースで公開。Kubernetesに対応 Google Cloud Platformのブログに投稿された記事「Scaling MySQL in the cloud with Vitess and Kubernetes」で、Vitessは次のように説明されています。 At YouTube, we went on that journey as we scaled our MySQL deployment, which today handles the metadata for billions of daily video views and 300 hours of new video uploads per minute. To do this, we developed the Vitess platform,
What's this? Docker, Inc is Dead の翻訳記事です。 ご本人の許可は取っていますが、僕が英語ペラペラではないため、読み辛いのはもちろん、一生懸命訳してはいますが誤訳・ミスリードなどあるかもしれません。 ですので、100%正確な内容を把握したい方は原文をお読みください。また、ここ間違ってるよ！ニュアンスが違うんじゃない？などありましたらお気軽に（優しく）コメントいただけると幸いです。 Docker, Inc is Dead / Docker社は死んだ Dockerにとって、2017年は非常に辛い1年だったと言っても過言ではありません。Uberを除いて、より活用され、賞賛され、十分に資金提供を受けたシリコンバレーのスタートアップの中で、Dockerが2017年に行ったような悪手を打ったスタートアップは思い浮かびません。人々は2017年を、ソフトウェアの偉大な一部分
こんにちは！スタンディングデスクを導入して快適な開発環境と運動不足の両方を解消できるようになったのではと感じている、広告技術部のUT@mocyutoです。 今回は半年ほどEKSを運用して秒間3万リクエストのトラフィックをさばくほどになりました。 秒間3万は広告システムだと割とあるとは思いますが、kubernetesでも運用できているので紹介しようと思います。 対象のEKSで構築したサービスは広告の配信サーバです。 広告配信サーバの要件として、まず50ms以内にレスポンスを返さなければいけません。 構築したk8sのレスポンスタイムの99パーセンタイルは10msほどで返せています。 以下は必要最小限のクラスタの構成図です。 全体像 API 弊社のサーバサイドはほぼGoで作られているので、例に漏れずGoで作られています。 pod構成はAPI、fluentd、envoyの サイドカーパターン です
本日開催されている Google Cloud Next ’18 ですが、非常に面白いプロダクトが発表されました。 その名も Knative (kay-nay-tiv ケイネイティブと発音) Kubernetes上でServerlessを実現するプロダクトです。 https://github.com/knative/docs より引用 KubernetesでServerlessって何が新しいの？ この界隈追っている方はご存じかもしれませんが、KubernetesでServerless Platformを実現するという考え方自体は新しいものではありません。 CNCF Serverless Landscape を見てみると分かりますが Fission Kubeless OpenFaaS などなど既に多くのOSSが存在しています。これら先行のServerlessプロダクトとKnativeは何が異な
Kubernetes 疲れに Azure Container Apps はいかがでしょうか？（江東区合同ライトニングトーク 発表資料）
最近のJava Webフレームワーク / Java Web Framework javaq2019
2019/6/25に行われたJavaコミュ@福岡での登壇資料です
デジタル トランスフォーメーションを加速 お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。
ZOZO×一休×PayPay AWS Nightは、2020年7月22日に開催されたZOZOテクノロジーズ・一休・PayPayの3社による合同イベントです。各社それぞれAWSの活用事例を紹介します。PayPay株式会社プラットフォームチームの西中氏がPayPayのインフラの概要について話しました（記事内の情報はイベント開催時点のもの）。 日本のNo.1 QRコード決済サービス 西中智樹氏（以下、西中）：「PayPayでのAWS活用事例について」と題して、PayPay Platformチーム・西中が発表いたします。 簡単に自己紹介します。西中智樹と申します。2018年12月よりPayPayで仕事をしていまして、現在、AWSなどのPayPayのインフラを所管するPlatformのチームに所属しています。好きなAWSサービスはEKSです。 本日のセッションのアジェンダになります。この順番でお話を
はじめに 最近、Kubernetesを中心としたコンテナ環境やマイクロサービスの文脈において、「サービスメッシュ」「Istio」というキーワードを聞く機会が増えています。 「Istio」は、2018/7/31にバージョン1.0に到達したことが発表され、ますます注目されるオープンソースソフトウェアとなっています。また、自分が所属しているSIerであっても、最近「サービスメッシュ」という言葉を聞く機会が増えてきています。 本記事では、サービスメッシュの概要から、サービスメッシュを実現するソフトウェアについて、Web上の情報などを元に調査した内容を整理したいと思います。 サービスメッシュとは マイクロサービスの課題 サービスメッシュの説明をする前に、サービスメッシュの前提となるマイクロサービスにおいて、どのような課題が存在するか整理したいと思います。 Service Discovery（サービス
くら寿司：GKE や Edge TPU などを駆使して来店から会計までを完全自動化し、新しい生活様式のためのサービスを提供 | Google Cloud 公式ブログ
くら寿司：GKE や Edge TPU などを駆使して来店から会計までを完全自動化し、新しい生活様式のためのサービスを提供 大阪を起点に日本全国 47 都道府県すべてに店舗を展開する大規模回転寿司チェーンくら寿司株式会社（以下、くら寿司）。浅草や道頓堀、原宿、押上に「食」と「エンターテイメント」の融合を掲げ、「ジャパンカルチャー」の発信拠点とするグローバル旗艦店をオープンするなど、とりわけ “体験” にこだわる同社が、最新のクラウド テクノロジーをどのように活用しているのか。その取り組みと成果を、テクノロジー開発部の皆さんに伺いました。 利用しているサービス： Google Kubernetes Engine、Compute Engine、App Engine、Edge TPU 利用しているソリューション： アプリケーションのモダナイゼーション コンテナや AI など Google Clo
KubernetesをGoogleが開発し、オープンソース化し、成功した経緯。関係者らが肉声で語るドキュメンタリー映像「Kubernetes: The Documentary」YouTubeで公開
KubernetesをGoogleが開発し、オープンソース化し、成功した経緯。関係者らが肉声で語るドキュメンタリー映像「Kubernetes: The Documentary」YouTubeで公開 ITエンジニア向けの転職紹介などキャリアサービスを提供しているHoneypot社は、Google、Red Hat、Cloud Native Computing Foundationの協力の下、Kubernetesの誕生から現在までをドキュメンタリー映像としてまとめた「Kubernetes: The Documentary」をYouTubeで公開しています（Part 1、Part 2）。 Do you know the story of @kubernetesio? Hear the details of how the project came to be from those who live
Red Hatは、同社が中心となってオープンソースで開発中のコンテナエンジン「Podman」がバージョン1.0に到達したことを発表しました。 Podmanはもともとコンテナエンジンの標準仕様であるOCI対応として開発されていた「cri-o」をベースに開発が始まったとされています。 Podmanはコンテナエンジンの標準仕様である「cri-o」に対応し、現在はDockerとほぼ同じDockerコマンドをサポートし、ベータ版のRed Hat Enterprise Linux 8にも同梱されています。 今回、Podmanが正式版となるバージョン1.0に到達したことで、Red Hat Enterprise Linux 8が正式版となったときにはDockerの代わりにPodmanが標準のコンテナエンジンになるとの指摘もあります。 Podmanのおもな特長は以下です。 Rootless containe
タイトル通りですが、1年目エンジニアのインフラのイの字も知らなかった私が1ヶ月半かけてKubernetesで環境構築するまでの失敗の軌跡です（そして環境構築できたのが奇跡）。 理想的にはこれを読めばインフラ初心者でもKubernetes（以下k8s）で環境構築できるところまで説明することですが、そういうわけでなく、環境構築の解説というより自分の失敗やつまづきポイント、役に立ったことをただただ書き連ねていきます。ただ他の初心者の方も同じようなところでつまづくこともあると思うので少しでもお役に立てたら嬉しいです。 バックエンド側で使った技術は以下になっています。 言語：Ruby（RoR） API：GraphQL インフラ：Azure その他：Docker、k8s 実際の実装でハマったところは各章の最後に教訓として簡単にまとめてはいますが、大事なことは先に結論として述べておきます。 Docker
コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。 脆弱性（ぜいじゃくせい）とは 脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティングシステムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。 潜在的な脆弱性を突いた新たなクラッキングの手口が、時間の経過ともに発見される。そのことから、開発当初はコードに脆弱性は無い
背景 最近、「コンテナはもうわかってきたので、これからKubernetesについて腰を据えて勉強したいが、どのように勉強すればいいかわからない」という相談をいただくことがすごく多くなった。 必要に応じて必要なリソースの挙動などを調べてきたし、僕自身も知らないことばかりなので、全てを伝えることはできない。 とはいえ、「入門しにくいサービスが伸びにくい」というのは、間違いないので、Kubernetesに入門する上でこの順番で学習したら、基本的な内容を身につけられるのではないかというロードマップを一つ公開しておくことで、これから業務でKubernetesを理解していく必要がある方の最初の一歩を助けられるかもしれないと思い、公開する事とした。(このQiitaのリンクを渡すだけで質問に回答できるという状態を作りたいという観点もある。) 自分の今の、Kubernetesに対する理解をうまく表現できてい
(ゲームの話は一切知らん) いつのまにか「Webフロントエンドの動きが速い」とか誰も言わなくなってることにふと気付いた。なんというかソフトウェアをどう作るか、という問題にたいして大枠の部分では完全に固まってしまって、あとは個別の事情をどうやっていくかみたいな話しか残ってないように見える。 端的にいえば、宣言的UIとkubernetesは聖杯だったのではないかな。 k8sにかんしては「Cloud Runみたいのでいいじゃん」みたいな話はあると思うんだけど、Envoyほしいとかなってくると結局事実上k8s必須だし、今新しくアプリ作るときに宣言的UIじゃないフレームワーク使うこととかほぼ考えられんよな。で、こういう構成が定番ですね、みたいになってなんかもう数年は経つ気がする。結果として日本語でソフトウェア開発の話になるとチームビルディングがどうのみたいな話しかなくなってきていて、なんかつまんねー
どのクラウドでも使えるサーバレス「GitLab Serverless」をGitLabが発表。KubernetesとKnativeがベース
どのクラウドでも使えるサーバレス「GitLab Serverless」をGitLabが発表。KubernetesとKnativeがベース GitLab ServerlessはKnativeをベースにKubernetes上で稼働するサーバレスプラットフォームです。GitLabがホスティングするのではなく、AWSやGoogle Cloud Platformなどどのクラウドに対してもデプロイし使えることが最大の特徴と言えるでしょう。 GitLabはマルチクラウドに対応したサーバレス管理ツールを提供するTriggerMeshと協力することで、デプロイ後の運用まで一貫してGitLabで管理できるとしています。 現在、AWS LambdaやGoogle Cloud Functions、Azure Functionsなど主要なクラウドは独自のサーバレスプラットフォームを提供しています。しかしそれぞれのク
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kubernetesがクラウド界の「Linux」と呼ばれる2つの理由
スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services
CIOpsとGitOpsの話 - inductor's blog
メンテのいらないソフトウェア - 誰かの役に立てばいいブログ
コンテナの軽量さと、より安全な分離を実現する「gVisor」、Googleがオープンソースで公開
Dockerfile書きたくないでござる
Kubernetes on AWS/EKSベストプラクティス2019.2 #jawsdays
【翻訳版】Docker, Inc is Dead - comix
秒間3万リクエストをkubernetesでさばく - Gunosy Tech Blog
最強のServerlessプラットフォーム？ Knative登場 - Cloud Penguins
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
コンテナ運用のベスト プラクティス | Cloud アーキテクチャ センター | Google Cloud
PayPayがAWSを使い続ける理由 日本No.1のQR決済サービスを支えるインフラ構成
サービスメッシュについて調査してみた件 - Qiita
Red Hatが開発するDocker互換の新コンテナエンジン「Podman」、バージョン1.0に到達
インフラど素人が1ヶ月半でKubernetes本番環境を作るまでの失敗の軌跡（奇跡） - Qiita
コンテナ・セキュリティ入門 脆弱性 - Qiita
Kubernetesに腰を据えて入門する方向けのロードマップ - Qiita
ソフトウェア開発の進歩完全に止まったような気がする