Movatterモバイル変換


[0]ホーム

URL:


はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

はてなブックマーク

タグ

関連タグで絞り込む (74)

タグの絞り込みを解除

serverに関するauientのブックマーク (122)

  • 自宅サーバの使いみち (2025-Q1)

    設置しているものだけでも19インチラックが2つ、NAS が4台 (うち1台は運用停止中)、ネットワーク機器は4台、汎用のノードが3台である。 実は画面外にデスクトップPC が3台あり、ラックマウントでも設置していないネットワーク機器が2台と汎用ノードの芽 (CPU と M/B 抜き) が1台あるが、今回は関係ないのでさておこう。 薄々気付いてはいたが、一般のご家庭にしては些か数が多いようだ。 計算機リソースが多いというのは言ってみれば家が広いようなもので、「そんなに家が広くて何になるの」などと言う人はそういない。 リソースというのはあればあるだけ自由度が高まる便利なもので、その嬉しさを問うなど愚問である。 とはいえ、では具体的にその自由度を何に使っているかとなると、これは環境の差や個性の出るところであろう。 私のサーバ環境もゆったりと変化を続けている。 定点観測というわけでもないが、折角

    自宅サーバの使いみち (2025-Q1)
      • クラウド型高速レンタルサーバー【スターサーバー】

        速さも安さも妥協しない、 国内最強コスパ※の レンタルサーバー 「スターレンタルサーバー」は最新技術を積極的に導入し、コスパ・性能ともに圧倒的No.1を目指しています。 圧倒的な性能に加え、 安さも両立した国内最速&コスパNo.1※レンタルサーバー 圧倒的な性能、対性能比で国内最安、業界No.1のコストパフォーマンスを追求します。 ※2025年8月19日、自社調べ。 サーバー速度については、自社サービスを除いた日国内シェア上位3サービスおよび独自に選定した国内の著名サービス・プランを含め、計6つのサービス・プランを対象に、h2loadを5回計測した結果によるもの。 複数プランがあるサービスについては、独自に選定したプランを除き、サービス内の最下位プランで計測した結果によるもの。 コスパ(コストパフォーマンス)は、上記6つの調査対象サービス・プランのサーバー速度の計測結果に対し、各サービス

        クラウド型高速レンタルサーバー【スターサーバー】
        • php-fpm の設定を理解してサイトのパフォーマンスを向上させる

          nginxWordpressサイトを運用する場合、php-fpmを利用することが多いかと思います。(Apacheでも利用することができますが)php-fpmの設定によって、Webサイトのパフォーマンスは左右されます。それだけでなく、不適切な設定はメモリリーク等につながるので、Webサイトにとって重要な設定であるといえます。 この記事では、そんなphp-fpm の設定の最適化方法について解説していきたいと思います。php-fpmの役割と特徴WordPress などの動的サイトは、Webサーバーがクライアントからリクエストを受けると、サーバー上でPHPを実行して動的にページを生成し、生成したページをレスポンスとしてクライアントに返します。 この、サーバー上でPHPを実行する仕組みがphp-fpmです。php-fpmでは、リクエストのたびにプロセスを生成していたのでは非効率なので、原則

          php-fpm の設定を理解してサイトのパフォーマンスを向上させる
          • Linuxコンテナの「次」としてのWebAssembly、の解説

            はじめにWASMをブラウザの外で動かすトレンドに関して「Linuxコンテナの「次」としてのWebAssemblyの解説」というタイトルで動画を投稿したのですが、動画では話しきれなかった内容をこちらの記事で補完したいと思います。2022年もWebAssembly(WASM)の話題が多く発表されましたが、そのひとつにDocker for DesktopWASM対応があります。FastlyやCloudflareもエッジ環境でWASMを動かすソリューションを持っていますし、MSのAKS(AzureKubernetes Service)でもWASMにpreview対応しています。WASMBuildersでも2023年のWASMの予想としてWASMのアプリケーションランタイム利用に関して言及されました。WASMといえば元々ブラウザ上で高速にC++のコードなどを実行するところから始まっている

            Linuxコンテナの「次」としてのWebAssembly、の解説
            • GitOps共有会

              信頼できる開発プラットフォームをどう作るか?-Governance as Codeと継続的監視/フィードバックが導くPlatform Engineeringの進め方

              GitOps共有会
              • WebAPIを構築する際にAPI Gateway+Lambdaを選択するべきか?

                はじめに このツイートに結構反響があったので、雑になるがとにかく自分の考えをダンプする。もともと書いていた記事はうっかりやらかしてデータロストした、泣きたい。 話をわかりやすくするために、ALB+ECS(Fargate)を使ってWebAPIと対比して説明しているが現実はもっと複雑である。 引用リツイートをもらえた部分などについてもアンサーっぽいことも書いていく。AWS利用費と人件費の話AWS上にWebAPIを構築する際に、AWS利用費の削減をモチベーションとしてApiGW+Lambda構成が、採用されることがある。確かにAWS利用費は下がるがApiGW+Lambda構成を設計〜運用するためにはAWSに関する知識の中でもとくに専門的な知識が必要になる。こういった人材を雇用または外部へ発注し続けることは人件費に跳ね返ってくる。ApiGW+LambdaがWebAPIのための構成として唯一無

                WebAPIを構築する際にAPI Gateway+Lambdaを選択するべきか?
                • auient
                  auient2021/03/27非公開
                  チューニングについてまとまってる
                  • Infrastructure as Dataとは何か

                    最近GCP から登場したKubernetesYAML の Package manager である Kpt は「Infrastructure as Data(Configuration as Data)」という考えかたを基礎としてそれを推し進めようとしている.それ以外にもKubernetes の Ecosystem には(明示はされていなくても)この考え方が中心にある.Infrastructure as Code とは何が違うのかなど歴史を振り返りつつまとめてみる. (指針はBorg, Omega, andKubernetesという論文にあるが「Infrastrcuture as Data(Configuration as Data)」という言葉を明確に定義した文章はない.この記事は References に挙げるいくつかのPodcast における@kelseyhightower

                    Infrastructure as Dataとは何か
                    • 個人開発ならHerokuよりDokkuを使おう - Qiita

                      皆さん個人開発してますか?個人開発の時にせっかく作ったならリリースして誰かに見てもらいたい・使ってもらいたいですよね。でもあまりお金はかけられない。 静的サイトならgithub.ioやfirebase hostingがありますが、Webアプリケーションだと使えません。 ちょっと前まではHerokuがデファクトな選択肢でしたが、スリープしたりで不便だったりします。 そんな方にDokkuがオススメです。 DokkuはOSSのPaaSで、シェルスクリプトを実行するだけでインストールができるHerokuライクなアプリケーションです。 自分はVultrという激安VPSにインストールしています。 実際どうなのか? インストール方法や基操作等は以下が参考になるので割愛します。 Getting Started with DokkuDockerでミニHeroku!「Dokku」をさくらのクラウドで試す

                      個人開発ならHerokuよりDokkuを使おう - Qiita
                      • sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました - ろば電子が詰まつてゐる

                        また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています。 今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。 当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンとnmapに絞って発表しました。 発表資料 私の発表資料は以下です。 (PDF)攻撃を「隠す」、攻撃から「隠れる」 発表ノート付きなのでPDFです。以下、落穂ひろいなど。 スキャンするポート数と

                        sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました - ろば電子が詰まつてゐる
                        • Let's EncryptでサーバをHTTPS接続に対応させた - rabbit2goのブログ

                          Amazon EC2で稼働させているサーバを、Let's Encryptを使ってHTTPS接続に対応させた。高いお金を払わなくても、無料でHTTPS接続が可能になるのだから便利な時代だ。 動作環境Amazon EC2AmazonLinux Apache 2.2 導入 下記の手順に従って導入すれば良く、問題は何も発生しなかった。sudocurl https://dl.eff.org/certbot-auto -o /usr/bin/certbot-autosudo chmod 700 /usr/bin/certbot-auto certbot-auto certonly --webroot -w /var/www/html -d [server] --email [mail_address] --debug Apacheの設定/etc/httpd/conf.d/ssl.confに

                          Let's EncryptでサーバをHTTPS接続に対応させた - rabbit2goのブログ
                          • auient
                            auient2016/07/04非公開
                            サーバの負荷分散の基本的な考え方
                            • srad.jp

                              We’re getting things ready Loading your experience… This won’t take long.

                              srad.jp
                              auient
                              auient2016/06/09非公開
                              DDNSのかわりにTorのOnionルーティングを使う話がよさそう
                              • GitHubユーザーのSSH鍵6万個を調べてみた - hnwの日記

                                (2015/1/30 追記)時期は不明ですが、現時点のgithub.comはEd25519鍵にも対応しています。 (2016/5/31 追記)「GitHubにバグ報告して賞金$500を頂いた話」で紹介した通り、既に弱い鍵はGitHubから削除され、新規登録もできなくなっています。GitHubAPIを利用して、GitHubの31661アカウントに登録されているSSH公開鍵64404個を取得してみました。抽出方法*1が適当すぎて偏りがあるような気もしますが、面白い結果が得られたと思うのでまとめてみます。 SSH鍵の種類 鍵の種類 個数 割合 RSA鍵 61749 (95.88%) DSA鍵 2647 (4.11%) ECDSA鍵 8 (0.01%) 約6万個の鍵のうち、8個だけECDSA(楕円DSA)鍵が見つかりました!常用しているのか試しに登録してみただけなのかはわかりませんが、何にせよ

                                GitHubユーザーのSSH鍵6万個を調べてみた - hnwの日記
                                • Linuxパフォーマンス調査などで使うコマンドメモ - Qiita

                                  パフォーマンスなどの調査をする時に利用する便利コマンドメモ。 これないぞ、あれないぞなどあると思いますがとりあえずなどを参考にまとめたものをピックアップしています。 参考 [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 絵で見てわかるシステムパフォーマンスの仕組みCPU使用率やメモリなど全体の概要把握top デフォルトでは3秒ごとにOSで利用しているプロセスの数や状態、またOS全体のシステムリソース状況が分かります。 パフォーマンスが悪い場合にOS全体としてどのリソースの利用が多いのか(CPU負荷なのかメモリ利用率が高いのか)などの判断に有用だと思われます。top - 22:36:56 up 28 min, 2 users, load average: 0.00, 0.02, 0.

                                  Linuxパフォーマンス調査などで使うコマンドメモ - Qiita
                                  • Herokuでbotを運用する時代は終わった。これからはIBM Bluemixを使って無料で運用する - Qiita

                                    2017/01/17追記Herokuのプランが変更されたようです。 詳しくは、コメント欄を参照してください。 追記ここまで みなさん、bot活用していますか? どんどん便利なスクリプトを追加し、日々の業務や生活になくなてはならない存在になっていると思います。しかしながら、botをどこで運用するかという悩ましい問題があります。少し前ならheroku一択でしたが、herokuのプランが変更され24時間完全に無料で運用することが難しくなりました。herokuで運用する問題点herokuは素晴らしい環境です。が、無料でbotをつくるとなると話は少し変わってきます。 30分アクセスしなければスリープ 24時間連続で動かすことができない(6時間のスリープ) hubot-heroku-keepaliveによって30分のスリープの問題はいいですが、24時間稼働できないのはどうしようもありません。まあ

                                    Herokuでbotを運用する時代は終わった。これからはIBM Bluemixを使って無料で運用する - Qiita
                                    • 現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠

                                      RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね(キリッ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした

                                      現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
                                      • ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ

                                        この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、PerlScalaGoもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。ScalaGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談

                                        ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
                                        • Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ

                                          主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。MySQLNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認top iostatnetstat / ss ログ調査 /var/log/messages or /var/log/syslog /

                                          Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ

                                          お知らせ

                                          公式Twitter

                                          • @HatenaBookmark

                                            リリース、障害情報などのサービスのお知らせ

                                          • @hatebu

                                            最新の人気エントリーの配信

                                          処理を実行中です

                                          キーボードショートカット一覧

                                          j次のブックマーク

                                          k前のブックマーク

                                          lあとで読む

                                          eコメント一覧を開く

                                          oページを開く

                                          はてなブックマーク

                                          公式Twitter

                                          はてなのサービス

                                          • App Storeからダウンロード
                                          • Google Playで手に入れよう
                                          Copyright © 2005-2025Hatena. All Rights Reserved.
                                          設定を変更しましたx

                                          [8]ページ先頭

                                          ©2009-2025 Movatter.jp