【1月23日追記】12月23日、24日に発生しました障害に関するご報告
いつもSkebをご利用いただき、誠にありがとうございます。 12月23日12時よりskeb.jpにアクセスできない大規模な障害が発生しておりましたが、12月24日07時に復旧いたしました。 12月23日、および12月24日が納品期限のリクエストは納品期限を12月25日23時59分までに延長させていただきます。 みなさまには多大なご迷惑をお掛けしましたことをお詫び申し上げます。 本障害につきまして詳細をご報告させていただきます。 概要日時: 12月23日12時22分〜12月24日7時00分 (JST) ダウンタイム: 18時間38分 内容: skeb.jpにアクセスできない不具合 原因: SkebはすべてのサーバとシステムをHerokuに設置していたが、障害発生時刻より同サービスのアカウントが理由の通知なく利用できなくなった。 解決: Herokuの一切の利用を中止し、すべてのサーバとシステ
コンテナで動くGoアプリをデバッグする方法
初めに 最近開発環境を整備していて、コンテナでGoアプリケーションをリモートでデバッグするのにちょっと面倒だったので、自分のメモも兼ねてやり方を残しておきます。 要件 プロジェクトによりますが、今の現場では主要エディタがVSCodeです。 もちろんVimユーザー（うち一人はぼく）がいるので、ターミナルでもデバッグできるように対応する必要があります。 また、コード変更を反映させるために都度イメージをビルドしてコンテナを再作成するは開発スピードが落ちるため、コンテナ再起動だけで反映されるようにする必要があります。 デバッガのしくみ Goにはdelveというデバッガがあります。 delveはClient-Serverモデルになっていて、次の2つのプロトコルで通信が可能になります。 JSON-RPC DAP JSON-RPCはdelveのCLIに使われています。 DAPはMicrosoftが策定し
Macで使うVS CodeとRemote Containerの性能を大幅改善 - Sweet Escape
はじめに なぜ遅いのか 何をやるのか 計測 名前付きボリュームを使ってない場合 Named Volumeを使う場合 Macからどう見えているか 結論とまとめ はじめに 以前からいろんなところで話していますが、僕は普段、手元のMacには言語系のランタイムとかは入れておらずVS CodeとDocker for Macだけ入れてRemote Containersの環境で開発しています。 この環境自体はとても便利でいいのですが、一点大きな問題があります。 それは遅いということ。自分の場合は最近だとJSでの開発が多いのですが、例えばNext.jsで開発している場合に以下のような操作が特に遅く感じます。 yarn install yarn add yarn jest next dev next start next build yarn jestとかnext devが遅いのは起動だけだったりします。起
Amazon Linux 2 の Dockerイメージから開発環境を作り Visual Studio Codeで接続してみる | DevelopersIO
Amazon Linux 2 の Dockerイメージから開発環境を作り Visual Studio Codeで接続してみる Amazon Linux 2のDockerイメージから開発環境として使うコンテナを作り、Visual Studio Codeで接続してみました。 コンテナは以下をインストール or 可能としてみました。 AWS CLIをインストールする。かつクレデンシャルはローカルのものをコンテナ内でも使えるようにする。 (開発言語として)Go言語をインストールする。 ローカルマシンとコンテナで共有できるフォルダを作成する。 以下、今回作成した「docker-compose.yml」と「Dockerfile」について書いていきたいと思います。 作成したもの ローカル環境について 本作業はMacで行いました。docker-composeとDockerがインストールされているものとしま
GitHub Actions のデバッグをローカルで行う
概要 GitHub Actions で GitHub ホストランナーを使用する場合、パブリックポジトリは無料ですがプライベートリポジトリは従量課金（無料枠あり）です。 ワークフローを編集する際にデバッグしていると結構な時間を消費してしまいます。 そこでデバッグ時は GitHub ホストランナーを使わずに無料で実行する方法を 3 種類紹介します。 nektos/act 言わずと知れたローカル実行ツールです。 すべてを再現することはできませんがコミットを増やさずにデバッグができます。 注意点 ubuntu-* のみサポート ソフトウェアは指定する Docker イメージ依存、デフォルトのイメージだと色々足りないので -P で指定 secrets.GITHUB_TOKEN が未定義なので Personal Access Token を発行し設定が必要 サービスコンテナ services が使えな
SaaS系スタートアップのリアルなAWSアーキテクチャ設計
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ
軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor's blog
はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基本的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで？ libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい
サーバレス、これからどうなる？ DDD＆サーバレスの第一人者が語る、技術の未来
注目しているサーバレスサービス 佃松三郎氏（以下、佃）：次ですね。「今注目しているサーバレスのサービスがあれば教えてください」。 丹羽一智氏（以下、丹羽）：サーバレスのサービスというと定義が難しいですけど。「サーバレスで開発されたサービス」なのか「サーバレス開発で使えるサービス」なのかというところで定義が難しいですが、そもそも世の中にフルサーバレスで動いているアプリケーションはほとんどないのが現状なので、「開発で便利なもの」という意味だと、何回か推しているんですが、Datadogがすごくおすすめです。 普通のアプリケーション開発をしていてもそうだと思いますが、「ログの扱いをどうしよう？」ということがずっと課題になっていて、Fluentdで集めてS3に置くということを、みんながんばってやっています。 DatadogにはLogsというサービスがあって、特定のポートにあるサービス、IP・ポートに
Dockerコンテナ内でpuppeteerを使うとChromeゾンビプロセスがたまる問題 - その手の平は尻もつかめるさ
表題のような問題があり，その調査したという記録です．なお，結論を一言で言うと--initを使え，ということになります． そもそもDockerコンテナを起動すると，CMDあるいはENTRYPOINTに指定されたコマンドがコンテナ内でPID 1として起動します．これが何を意味するかと言うと，「CMDあるいはENTRYPOINTに指定されたコマンド」はそのコマンド自体の責務をまっとうするのと同時に，initプロセスとしての振る舞いも行わなければならないということになります (id:hayajo_77さんにこの辺を詳しく教えてもらいました，ありがとうございます)． つまりPID 1で動いているプロセスは「SIGCHLDをトラップすることで孤児プロセスを適切に回収し，waitpidをかける」という処理も適切に行う必要があります． さて，puppeteerを使ってChromeブラウザを起動するとどうな
コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ - kakakakakku blog
2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ．タイトルの通り，コンテナのデザインパターンがまとまっていて，これからコンテナ設計をする人も，既にコンテナを運用している人も，デザインパターンを学べるのは価値があると思う．一部ミスリードをしているかもしれない． Design patterns for container-based distributed systems 論文も公開されている． https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern
「全然わからない。俺たちは雰囲気でコンテナをやっている」 /operating-containers-just-with-a-hunch
Hacker Tackle 2018 発表資料
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
