Posts

nginxのメトリクスとログをモニタリングをする メトリクスデータは以下のように流す nginx -> vector -> kafka -> opensearch/influxDB という感じで、nginxから出た生ログをvectorでとり、kafkaに送信、kafkaから、opensearchとinfluxDBがそれぞれとってくる、という流れにするのが良さそう で、nginxがログを吐き出し/var/log/nginx/access.logとvectorを同じネームスペースで扱いたいので、この二つは物理マシン上にインストールするという流れにしたいと思う。 環境構成 以下の3つのマシンを使う delta (100.64.1.48,192.168.3.1) : 192.168.3.1/24のルータ,kafka, kafka-ui, opensearch master (192.168.3.8) : プロキシサーバ（nginx）、vector gamma/zeta/　: オリジン kafkaを導入するdocker composeの設定 services: kafka-broker: image: apache/kafka:3.7.0 container_name: kafka-broker ports: - "${KAFKA_BROKER_LOCAL_PORT}:9092" environment: KAFKA_NODE_ID: 1 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT" KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT_HOST://localhost:${KAFKA_BROKER_LOCAL_PORT},PLAINTEXT://kafka-broker:${KAFKA_BROKER_PUBLIC_PORT}" KAFKA_PROCESS_ROLES: "broker,controller" KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka-broker:${KAFKA_BROKER_CONTROLLER_PORT}" KAFKA_LISTENERS: "CONTROLLER://:${KAFKA_BROKER_CONTROLLER_PORT},PLAINTEXT_HOST://:${KAFKA_BROKER_LOCAL_PORT},PLAINTEXT://:${KAFKA_BROKER_PUBLIC_PORT}" KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT" KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER" KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0 KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1 KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1 KAFKA_LOG_DIRS: "/tmp/kraft-combined-logs" kafka-ui: container_name: kafka-ui image: provectuslabs/kafka-ui:v0.7.2 ports: - "${KAFKA_UI_PORT}:8080" depends_on: - kafka-broker restart: always environment: KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} init-kafka: # kafka-topics コマンドを使いたいので confluenticsのコンテナを利用 image: confluentinc/cp-kafka:7.6.1 container_name: init-kafka depends_on: - kafka-broker entrypoint: ["/bin/sh", "-c"] command: | " # blocks until kafka is reachable kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --list echo -e 'Creating topics' kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --create --if-not-exists --topic nginx-log --replication-factor 1 --partitions 1 echo -e 'Successfully created :' kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --list " opensearchを導入する設定 version: '3' services: opensearch-node1: # This is also the hostname of the container within the Docker network (i.e. https://opensearch-node1/) image: opensearchproject/opensearch:latest # Specifying the latest available image - modify if you want a specific version container_name: opensearch-node1 environment: - cluster.name=opensearch-cluster # Name the cluster - node.name=opensearch-node1 # Name the node that will run in this container - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Nodes to look for when discovering the cluster - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Nodes eligible to serve as cluster manager - bootstrap.memory_lock=true # Disable JVM heap memory swapping - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD} # Sets the demo admin user password when using demo configuration, required for OpenSearch 2.12 and later ulimits: memlock: soft: -1 # Set memlock to unlimited (no soft or hard limit) hard: -1 nofile: soft: 65536 # Maximum number of open files for the opensearch user - set to at least 65536 hard: 65536 volumes: - opensearch-data1:/usr/share/opensearch/data # Creates volume called opensearch-data1 and mounts it to the container ports: - 9200:9200 # REST API - 9600:9600 # Performance Analyzer networks: - opensearch-net # All of the containers will join the same Docker bridge network opensearch-node2: image: opensearchproject/opensearch:latest # This should be the same image used for opensearch-node1 to avoid issues container_name: opensearch-node2 environment: - cluster.name=opensearch-cluster - node.name=opensearch-node2 - discovery.seed_hosts=opensearch-node1,opensearch-node2 - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 - bootstrap.memory_lock=true - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD} ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 volumes: - opensearch-data2:/usr/share/opensearch/data networks: - opensearch-net opensearch-dashboards: image: opensearchproject/opensearch-dashboards:latest # Make sure the version of opensearch-dashboards matches the version of opensearch installed on other nodes container_name: opensearch-dashboards ports: - 5601:5601 # Map host port 5601 to container port 5601 expose: - "5601" # Expose port 5601 for web access to OpenSearch Dashboards environment: OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' # Define the OpenSearch nodes that OpenSearch Dashboards will query networks: - opensearch-net volumes: opensearch-data1: opensearch-data2: networks: opensearch-net: nginxを導入する設定 これは普通に ...

Real world httpに書いてあることを殴り書きしていきます 開発環境 の前に、lanのipアドレスを書いておきたいです。 100.64.1.27 : alpha 100.64.1.61 : evn 100.64.1.48 : delta (K8SクラスタへのGWです) deltaの役割 前に、DHCPサーバとルータを作成する記事を書いた。 こちらの記事だね。 で、deltaはDHCPサーバ兼ルータという立ち位置です。

2024/11/1時点でのタスクリスト 開発関係 自宅のK8S上にecho-serverを立てて、proxyを複数立てて、さらにvipを立てて、vegetaで負荷試験ができるようにしたい。そして、様々なメトリクスが取れるようにしたい。どうやるんだろうか。流れ的には、だいぶ遠回りになることは承知だが、 まず、real-world-httpを読みたい。これは、だいぶ長いのよね。メモを取りながら進めていく。最終目的はプロキシ2台とecho-server1台の構成で、vegetaで負荷をかけられるようにすること。 うちのも参考にするといいかも。そして、壊して学ぶk8s的な本を買ったので、それを読んで、goで書いたecho-serverをラズパイにデプロイするる感じでやりたい。これをいつまでにやるかだけど、 ISUCONの過去問を解きましょう。今年のISUCONにおそらく白木さんと出ることになります。足を引っ張りたくないので頑張ります。 ーー＞isucon14の申し込みが始まったという話です。頑張りましょう。 会計ソフトを導入する。この辺が良さそう https://ledger-cli.org/ 合同会社の設立を進める I and shiraki-san decided to develop GSLB using go lang. It is going to be funny Learn DNS （こっちはかなりいい感じで進んでいる。） –> Done Learn How to write packer parser using Go on TCP Layer. It is also going to be funny. 例の競馬システムを動かす時が来た。自宅のk8sで動かせるようにmanifestファイルを書いてください。よろぴくお願いしますです。 Go言語でdistributed file systemを作ってくれ！このyoutubeを見てでもいいし、goで分散システムを作ろうって入ってきたあの本でもいい。どっちでもいい。ただ、後者だとk8s上に作った分散システムを展開するので、上のやつとも親和性が高い気がしています。はい。 その他 毎朝早く起きてくれ。23時に寝て0630に起きる生活ができると最高だ。 早く業務委託で何かしらの案件を取ってきて売れ。 早くyoutubeチャンネル開設して、経費生活を始めてくれ！ 長期目線 簿記2級とってくれ！ 土地をどこに買うかかんがえてくれ！！そして貯金しろ！！マジな話、生活費8万と、共通貯金口座5万以外は全部あっちに回してくれ。 つまり、月のクレカ支払いに使えるお金は17万ということになる。保険で10マン落とされるので、残り7万か。まあそんなものやろう。

ECDH完全理解した。 参考 ECDHを紹介するyoutube 楕円曲線暗号をビリヤードに例えている例 ECDHの説明 かなり面白いね。ECDH。 まず、楕円曲線上で足し算というものを定義する。 これは、ビリヤードである。二点を決めて、その直線を引くと新たに楕円曲線と交わる点が生じる。それをx軸に対象に折り曲げた点、これを足し算の結果とする。 a + b = c ここで、p + p = 2pというものを定義可能である。pというのは、接線となる。 で、ここで不思議なのが、以下の結合法則が成り立つこと。 p + 2p = 3p 3p + p = 4p 2p + 2p = 4p 先に p + 2p = 3p 3p + p = 4p を計算して出した4pも 2p + 2p = 4p で出した４pも同じ点になる。これは面白い。 でだ、 こんな感じで最初の点Gを決めて、k倍した点Q Q = kP を求めることは簡単である。（例えば、k = 128の時は、2p+2p, 4P+4p,,,, 64p+64pで計算関数は少なく済む。） しかし、QとPからkを求めることは困難である。前から順番にやっていくしかないのである。 ということで、Qという値をサーバとクライアントで生成するんだよね。それぞれ、Q1,Q2. Q1 = K1P Q2 = k2P そして、Q1とQ2を交換します。opensslではRSAなどで署名が施されて交換されるので、真正性も担保される。 で、プリマスターシークレットを、 Q = K1K2P として、鍵交換が完了。これを元に共通鍵を生成して暗号通信がスタートする、という感じだ。 素晴らしい。 楕円曲線暗号のイメージは、以下のように説明されています。 ...

公開鍵暗号の体系を完全に理解した はい、鍵交換アルゴリズム、署名アルゴリズム、暗号アルゴリズム、暗号モード、ハッシュ の５つのセット（暗号スイート）を指定して通信を暗号化する。それが、俺が知っている暗号体系の全てです。 でですね、openVPNでクライアントとサーバの通信を暗号化しますよね。 その時に色々と証明書を発行すると思うんですよ。ただ、俺はどの証明書がどのように用いられるのかが全くわかっていなかった。 だから、今回、改めてopenVPNでクライアントとサーバを構築する際の証明書の役割などを確認したいと思う。 過去の僕の記事 basic client site to site routeing いつも参考にしている記事 qiita では追っていきましょう 認証局 (CA) の設立 ここから始まっているっぽいんだよね。 $ ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: path/to/easy-rsa/easyrsa3/pki CA証明書の生成 $ ./easyrsa build-ca パスフレーズが聞かれる。 ここで、秘密鍵と公開鍵がすでに生成されている。認証局のね サーバ証明書の生成 $ ./easyrsa build-server-full server nopass ここで、CA証明書を生成したときのパスフレーズを再び入力する。 これでおそらく、サーバの公開鍵に署名がされる。(CSRも済んでいる) DH鍵の生成 ここでDH鍵が生成されるのか。なぜだ？？TLSでのDH鍵は毎回違うものが使われるのではないのか！？ なるほど、chatGPTに聞いたのであっているかはわからんが、この段階で生成されるものは、DHパラメータ（素数と生成元）だね。 これは納得だね。 つまり、 y = g ^ (x) mod p の、pとgが生成される。で、サーバとクライアントはお互い適当にxを選ぶわけですわ。はい完全理解。 ちなみに、ecdhを使って鍵交換をすることもできます。 証明書失効リストの生成（こちら、参照しているページでは間違っているので注意が必要） $ ./easyrsa gen-crl こちらも、CAの秘密鍵で署名するわけですね。 クライアント用秘密鍵の生成 $ cd easy-rsa/easyrsa3 $ ./easyrsa build-client-full username はい、ここでクライアントの証明書と秘密鍵を生成するわけですね。 で、証明書はCAが認証する必要があるので、再びパスフレーズを入れる感じになります。 ...

前提知識 TLSでは、 鍵交換アルゴリズムを使って共通鍵の材料となる値を交換し、共通鍵を生成し、その鍵を用いて通信が暗号化されるわけですね。 鍵共有に使われる暗号を、公開鍵暗号と言いますね。共通鍵は、共通鍵暗号です。 公開鍵暗号 RSA DH ECDH DEH = DH ephemeral ECDHE = ECDH epemeral DHとECDHは離散対数問題を使っています g^x mod p = y で、y,p,gが与えられたとき、xが求められないってことね 共通鍵暗号 RC4 (危殆化) DES = (危殆化) 3DES きたいか ChaCha20 AES = 最も使われていて安全 RC4 = ストリーム暗号 AES = ブロック暗号 ハッシュ関数 MD5 SHA-1 SHA-2 SHA-3 TLSの暗号スイートについて はい、これすごく大事なこと言います。TLSを使って通信が暗号化されるまでの流れですね。 TLSハンドシェイク 実際にTLSの通信が始まる でですよ。TLSハンドシェイクで何を決めているか？なんですが、以下を決めているわけですね。 鍵交換アルゴリズム 署名アルゴリズム 暗号アルゴリズム 暗号利用モード ハッシュ関数 鍵交換アルゴリズムは上に書いた、RSA,ECDHE,DHEです。 署名アルゴリズムは、RSA/ECDHEを指定できますが、ここは、発行したサーバ証明書の鍵の種類に依存します。ここすごく大事。 実は、鍵交換アルゴリズムで生成されたあたいは、さらにサーバ証明書の秘密鍵で暗号化され、公開鍵で復号されるんですね。で、真正性を確かめるんですよね。 ここ、知らんかった。すごく大事。 ただ覚えておきたいのが、RSAを用いた鍵交換では、署名がなされないということ。証明書の公開鍵は、クライアントが生成したプリマスターシークレットを暗号化するために使われる。そして、秘密鍵で復号するんだよね。 ECDHEでは、毎回公開鍵が生成されるんだよね。で、その公開鍵の正当性を証明するために秘密鍵で署名し、公開鍵で検証するんだよね。 RSAを用いた鍵交換では毎回同じ公開鍵と秘密鍵のペアで通信がなされるんだよね。プリマスターシクレットも含めてね。 だから、スノーデン事件の時みたいに、暗号化されたものをずっと溜めておいて、後でどうにか秘密鍵を入手して、プリマスターシクレットを特定、 からの通信内容を特定、といったことができてしまうんだよね。これ、前方特秘性がないって言いますね。 これに対して、ECDHE、DHEは、一回一回秘密鍵と公開鍵を生成するんだよね。はいそうだね。 でも、公開鍵から秘密鍵は、頑張れば何年かかければ、推測可能だよね？だから前方特秘性は、ないと思うんだけど。 これをchatGPTに聞いてみたらこう帰ってきました。 Q. 離散対数問題は時間をかければ解読可能です。各セッションで使われる公開鍵から秘密鍵を割り出すことも、原理上は可能です。 そこで、各セッションの公開鍵と、暗号化された通信全てを保存している人がいたとしましょう。そうすると、時間さえかければ、暗号文を解読できると思うのですがいかがでしょう。 ...

やりたいこと k8s上にechoサーバを分散させる プロキシサーバ (nginx) を立てて、そいつらに負荷分散できるようにする Mtailを使って、nginxのログを収集して、prometheus形式に変換、telegrafで取得しinflux Dbに送信　（このときにタグもつけたいかも） Cloudproberでnginxを監視したい。cloudprober -> prometheusに変換 -> telegrafで取得しinflux DBに送信（タグもつけたいかもしれない） 以上を全てansibleを使って実現したいという話だよね。厳しいかな。どうかな？？ 正直k8sは必須ではない。時間がかかりそうであれば、先にgoとかで簡単なecho-serverを作って1を完了させてしまうのも全然あり。 今回の目的はあくまでnginxのモニタリングをガチガチにするってことだからね。でも、k8sの監視はちょっとしてみたいかもしれないね。 最初からprometheus形式でexportしてくれるみたいだからね。気になるところではあります。 ただ、k8sはその性質上、コンテナをデプロイするから、どこからコンテナを取ってくるかを決める必要がありますね。外部に漏らしたくない情報が入っているのであればprivateリポジトリを立てるしかない。そうでなければdocker hubでいいかな。

背景 Mysqlをデータベースにしてサービスを運営している。 しかし現在、Mysqlのバックアップは取っておらず、元データが消えたら全データが消える状況である。 そこで、元サーバで毎日指定された時刻にmysql_dumpをし、バックアップサーバが元サーバからデータを持ってく量なcronジョブ を作りたいと思っている。 注意点としては、本番サーバはグローバルに、バックアップ鯖はローカルネットワークにいるので、グローバルからローカルには送れないってこと。（vpnとか貼ったらいけるけどめんどい）ので、バックアップサーバもcronでscpを動かして定期的に鶏肉という感じ。 AC 毎日元サーバから吐かれたmysqldumpファイルがバックアップサーバに置かれた状態になっている 関連技術 cron 参考 設定ファイル /var/spool/cron/crontabs/<user name> が設定ファイルです。 rootユーザ用のcronを設定する方法は、 sudo vim /var/spool/cron/crontabs/root って感じで開けます。 このファイルに実行したいジョブと実行日時（実行間隔も指定可能）を指定します。 0 * * * * /home/backup.sh 五つの*が何を表すかですが、 「分 時 日 月 曜日」 結構忘れがちなのが、シェルスクリプトのパーミッションでexecuteが入ってなくてエラーになることが多いので気をつけて。（上の/home/backup.sh） ログについて（ubuntu） デフォルトではログが出力されないようになっている。 こちらを参考にログを出力するように設定を変える vi /etc/rsyslog.d/50-default.conf # コメントアウト cron.* /var/log/cron.log # リスタート service rsyslog restart mysqldump 参考文献 こちら 上のによると、特定のユーザが持っているデータベースをダンプする方法は以下のようになるかな。 mysqldump -u hoge -p -B some_database > database.sql ちなみに、パスワードの入力まで自動でやるとするとこんな感じです。 0 21 * * * mysqldump -u -hogehoge --password="hogehoge" --no-tablespaces DB_NAME > /hoge/database.sql 毎日21:01にSCPでとってくるcron jobをしくむ。さらにdbへの流し込みもやってくれると最高だよね〜。 まず、scpでpasswordを打たなくていいように鍵をリモートサーバに登録 sudo vim /etc/ssh/sshd_config # 以下をコメントアウト PubkeyAuthentication yes ssh-keygenで秘密鍵と公開鍵を生成 パスフレーズを入れないのがポイント ...

事始め isuconに出ることになった。 参考 ブログ記事 isucon参加申し込み isucon TOP 気をつけたいこと 必ずリリースバージョンをつけること。これは大事な気がする。動かなくなることがあるからね github上で管理するのがいいと思う。 役割分担 Ansibleでデプロイするためのplaybook、inventoryを作成 kernel parameter tuning 簡単にいうとこんな感じよね nginx tuning OCSP stapling Session resumption (tickets) Session resumption (caching) False Start (NPN needed) HTTP/2 あとは、この辺もやったらいいかもね。あんまり上がらんかもしれんけど worker_processes auto; # コア数と同じ数まで増やすと良いかも # nginx worker の設定 worker_rlimit_nofile 4096; # worker_connections の 4 倍程度（感覚値） events { worker_connections 1024; # 大きくするなら worker_rlimit_nofile も大きくする（file descriptor数の制限を緩める) # multi_accept on; # error が出るリスクあり。defaultはoff。 # accept_mutex_delay 100ms; } http { log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time'; # kataribe 用の log format access_log /var/log/nginx/access.log main; # これはしばらく on にして、最後に off にすると良さそう。 # access_log off; # 基本設定 sendfile on; tcp_nopush on; tcp_nodelay on; types_hash_max_size 2048; server_tokens off; # open_file_cache max=100 inactive=20s; file descriptor のキャッシュ。入れた方が良い。 # proxy buffer の設定。白金動物園が設定してた。 # proxy_buffers 100 32k; # proxy_buffer_size 8k; # mime.type の設定 include /etc/nginx/mime.types; # Keepalive 設定 keepalive_timeout 65; keepalive_requests 500; # Proxy cache 設定。使いどころがあれば。1mでkey8,000個。1gまでcache。 proxy_cache_path /var/cache/nginx/cache levels=1:2 keys_zone=zone1:1m max_size=1g inactive=1h; proxy_temp_path /var/cache/nginx/tmp; # オリジンから来るCache-Controlを無視する必要があるなら。。。 #proxy_ignore_headers Cache-Control; # Lua 設定。 # Lua の redis package を登録 lua_package_path /home/isucon/lua/redis.lua; init_by_lua_block { require "resty.redis" } # unix domain socket 設定1 upstream app { server unix:/run/unicorn.sock; # systemd を使ってると `/tmp` 以下が使えない。appのディレクトリに`tmp`ディレクトリ作って配置する方がpermissionでハマらずに済んで良いかも。 } # 複数serverへ proxy upstream app { server 192.100.0.1:5000 weight=2; // weight をつけるとproxyする量を変更可能。defaultは1。多いほどたくさんrequestを振り分ける。 server 192.100.0.2:5000; server 192.100.0.3:5000; # keepalive 60; app server への connection を keepalive する。app が対応できるならした方が良い。 } server { # HTTP/2 (listen 443 の後ろに http2 ってつけるだけ。ブラウザからのリクエストの場合ssl必須） listen 443 ssl http2; # TLS の設定 listen 443 default ssl; # server_name example.jp; # オレオレ証明書だと指定しなくても動いた ssl on; ssl_certificate /ssl/oreore.crt; ssl_certificate_key /ssl/oreore.key; # SSL Sesssion Cache ssl_session_cache shared:SSL:10m; ssl_session_timeout 1m; # cacheする時間。1mは1分。 # reverse proxy の 設定 location / { proxy_pass http://localhost:3000; # proxy_http_version 1.1; # app server との connection を keepalive するなら追加 # proxy_set_header Connection ""; # app server との connection を keepalive するなら追加 } # Unix domain socket の設定2。設定1と組み合わせて。 location / { proxy_pass http://app; } # For Server Sent Event location /api/stream/rooms { # "magic trio" making EventSource working through Nginx proxy_http_version 1.1; proxy_set_header Connection ''; chunked_transfer_encoding off; # These are not an official way # proxy_buffering off; # proxy_cache off; proxy_pass http://localhost:8080; } # For websocket location /wsapp/ { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_pass http://wsbackend; } # Proxy cache location /cached/ { proxy_cache zone1; # proxy_set_header X-Real-IP $remote_addr; # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # proxy_set_header Host $http_host; proxy_pass http://localhost:9292/; # デフォルトでは 200, 301, 302 だけキャッシュされる。proxy_cache_valid で増やせる。 # proxy_cache_valid 200 301 302 3s; # cookie を key に含めることもできる。デフォルトは $scheme$proxy_host$request_uri; # proxy_cache_key $proxy_host$request_uri$cookie_jessionid; # レスポンスヘッダにキャッシュヒットしたかどうかを含める add_header X-Nginx-Cache $upstream_cache_status; } # Lua location /img { # default_type 'image/svg+xml; charset=utf-8'; content_by_lua_file /home/isucon/lua/img.lua; } # WebDav 設定。使いどころがあれば。 location /img { client_body_temp_path /dev/shm/client_temp; dav_methods PUT DELETE MKCOL COPY MOVE; create_full_put_path on; dav_access group:rw all:r; # IPを制限する場合 # limit_except GET HEAD { # allow 192.168.1.0/32; # deny all; # } } # static file の配信用の root root /home/isucon/webapp/public/; location ~ .*\.(htm|html|css|js|jpg|png|gif|ico) { expires 24h; add_header Cache-Control public; open_file_cache max=100 # file descriptor などを cache gzip on; # cpu 使うのでメリット・デメリット見極める必要あり。gzip_static 使えるなら事前にgzip圧縮した上でそちらを使う。 gzip_types text/css application/javascript application/json application/font-woff application/font-tff image/gif image/png image/jpeg image/svg+xml image/x-icon application/octet-stream; gzip_disable "msie6"; gzip_static on; # nginx configure時に --with-http_gzip_static_module 必要 gzip_vary on; } } } Database tuning レプリカを作ったりしてね。 mysqlでのレプリカの作り方がわからなかったりもするが。 あと、どうやってアプリを分散させるのか、というのもわからなかったりする。 ...

この記事の流れ opensslで秘密鍵を発行してみる 秘密鍵の中身を見る RSA暗号の解説。証明。 rsa暗号でサーバ証明書を発行するまで SAN付きのサーバ証明書の作り方 lets encryptでsan付きのサーバ証明書が作れるか そもそもsslサーバ証明書とは？ 「サーバー証明書」とは、「通信の暗号化」「Webサイトの運営者・運営組織の実在証明」の2つの役割をもつ電子証明書です。 です。つまり、証明書には、暗号化用の鍵＋証明書が入っている、ということになる。いいですね。 秘密鍵の中身をのぞいてみる。 秘密鍵の作成 $ sudo mkdir /etc/nginx/ssl $ sudo openssl genrsa -out /etc/nginx/ssl/server.key 512 秘密鍵を作っているけど、公開鍵はどこにあるのか？？というのが非常に気になります。ていうか秘密鍵が因数分解されたものなんだっけ？ だからいいのか。掛け算したら一瞬でわかるって話か。おけ。ってことでさ、適当に鍵を一つ作ってみたんだよ。 ちなみに、512bitより短い鍵は作れません。これすごいよね。 -----BEGIN PRIVATE KEY----- MIIBVAIBADANBgkqhkiG9w0BAQEFAASCAT4wggE6AgEAAkEA4dNuxX/SzX3wEhde FmNFXLWlNkbGq4xaU6CfKy2nI9K+SWSKueJWSjoanmEG1eb6cXozmAk4eiuKm7zv +FdQowIDAQABAkB+1CdnRoXXIT7eej8+ZZyEGARkulVD7XyhcRlTv70aMWjC29cG 1LIeSScmy5ChqoGwH9Ow/BRzZXax3yeqMQFJAiEA9m+ardfTOK/xVoSn3I5pkzoR prW2xLQi0IDsv5lEu3UCIQDqlxAo6aDT0KpBBe5HbxBgw7uf34G+m7LJs/JnoMYQ twIgALXvr0KpFEfFnWdCiKtMeKU5Oc7aWRTf6NQGWsMZZKUCIFxk6wRyH9nNEYFS qKqR3818yeUJzrwX7q7qpMqT0+65AiEAqWRxDU6t8ZjPmJd6B7w481FuwrFmF9cq mq+QXX8gjRw= -----END PRIVATE KEY----- echo "MIIBVAIBADANBgkqhkiG9w0BAQEFAASCAT4wggE6AgEAAkEA4dNuxX/SzX3wEhde FmNFXLWlNkbGq4xaU6CfKy2nI9K+SWSKueJWSjoanmEG1eb6cXozmAk4eiuKm7zv +FdQowIDAQABAkB+1CdnRoXXIT7eej8+ZZyEGARkulVD7XyhcRlTv70aMWjC29cG 1LIeSScmy5ChqoGwH9Ow/BRzZXax3yeqMQFJAiEA9m+ardfTOK/xVoSn3I5pkzoR prW2xLQi0IDsv5lEu3UCIQDqlxAo6aDT0KpBBe5HbxBgw7uf34G+m7LJs/JnoMYQ twIgALXvr0KpFEfFnWdCiKtMeKU5Oc7aWRTf6NQGWsMZZKUCIFxk6wRyH9nNEYFS qKqR3818yeUJzrwX7q7qpMqT0+65AiEAqWRxDU6t8ZjPmJd6B7w481FuwrFmF9cq mq+QXX8gjRw=" | base64 --decode これでデコードしてもバイナリだからなんもわからんわ。 いかのスクリプトでデコードできるみたい。 from Crypto.PublicKey import RSA # Load the private key with open("private_key.pem", "r") as file: private_key = file.read() # Parse the private key key = RSA.import_key(private_key) # Extract the components n = key.n # Modulus e = key.e # Public exponent d = key.d # Private exponent p = key.p # Prime 1 q = key.q # Prime 2 print(f"Modulus (n): {n}") print(f"Public exponent (e): {e}") print(f"Private exponent (d): {d}") print(f"Prime 1 (p): {p}") print(f"Prime 2 (q): {q}") Modulus (n): 11827462552050103756019456673259686146276364164688350469602565108471900615793415256864500417710852720839063036792768824435280979352135219586691204539437219 Public exponent (e): 65537 Private exponent (d): 6642559381010851411383007183311248119169234719466623674178885422700539328402280041863549141435055457596044186231508711647457747564061370576607226853654857 Prime 1 (p): 111466148331411145531384799415569793304697439187343498431136600736302912289653 Prime 2 (q): 106108112006209210762976910352826494821357000184205525073929931397132009738423 ということですね。はい。 はい、でさ、RSA暗号の仕組みも今勉強してしまいましょうか。 ...