January 22, 2023
竹書房 plotted nibbler
ええ本無いな、ダメな方に誘導しているだけで読まん方がいいよな
どうでもええ、科学的でも前進が少ない、分かりにくい、本となっていない
上梓しましたよ～という為だけにある
レビューも信用ならん
適当なことを言っているだけ、逆誘導
逆に生産性が無さそうな批評家、評論の方がええかも
といっても、私も逆誘導だよ～ん
ということで… ベリベリベリ竹書房復活ってdoDow
/// 支配の構造 国家とメディア――「世論」はいかに操られるか
仏）フランス革命で労働者が団結して職能組合や結社を厳しく制限
中間共同体を認めず、ルソーの社会契約論に影響された
国家は個人の自由意思に基づく契約により成立、一般意思こそが公の利益を達成する
党派、結社は私的団体であり、私的利益誘導するでなく個人になれと
実際には党派なのに個人と言い張ることが起こる
米）タウンシップがデモクラシーの下支え
地域に根差す自治的な中間共同体、つまり教会
中産階級が階級的ではなくフラットな個人として関係性を結ぶ
中間共同体が国家権力の防波堤になり、パブリックマインドの教育の場となる
行き過ぎた個人主義から共同体を見直す動きも
結社としてのメディア＝ローカルニュース
選挙は神の見えざる手、デモクラシーには見えない神の存在があると思っているのでは
プロテスタントの救済、神の国に行くのは厳格で難しい
カトリックは懺悔をすればいいが、Pは大抵の人は救済されないと考えている
救済される自分は救済されない堕落した人間とは付き合えない
つまりエリートとしての連帯は強く救済される同志
人の間で同時性を認識できると共同体やネーション等の連帯感が現れる
同じニュースを見る事、昔は新聞で同時性がありメディアが連帯を近年作りだした
昔はどこに巡礼するかで共同体が決まった、共同体から代表2名で伊勢に行ったとか
ネットはバラバラに小世界を点在させ、相互交流はしない
検閲や強制や弾圧でなく、社会の変化に従って、大衆が自ら忖度し発禁していくだろう
ちびくろサンボ、アンクルトムの小屋、煙草と肺がん、コロナ、陰謀
誰かにとって好ましくないものは何も考えずに燃やしてしまえば平穏無事だ
自分の頭で考えているような気になる、動かなくても動いているような感覚になる、ニュースのみをぎっしり詰め込んでやれ
/// 知ってはいけない現代史の正体
waspはもう米国を支配していない
排他的だったwaspは > 同一化 > 多様性 > というメディア世論で没落 > DS
多文化共生を一つの国家で行えない（DSの分断戦略、欺瞞、国家は単一文化が自然）
戦争紛争を利用し利益を収奪
シリアに介入したい（反アサド⇔ISIS（悪者）←育てる/武器を供給）＞無政府状態にした後＞介入
時に両方に付く、時に片方、だが裏切ることもある
自由と民主主義は国際介入政策を正当化する口実
- 民主化＞民営化＞グローバル市場化→国民主権の喪失
- グローバリズム→民族文化を破壊し金融で独裁支配する社会主義化
歴代大統領：グローバリズム←影のキングメーカ：国際金融資本家のコントロール下
トランプ：アメリカファースト/ナショナリズム
プーチン：反グローバリズム
中国：共産党独裁国家、超個人主義、中国人に国家観はない（儲かればいい）→世界のリーダになり得ない
/// アンジャッシュ渡部の 大人のための「いい店」選び方の極意
食の楽しみ、開拓の楽しみ
相手の苦手なものを確認、行きたいところを調べて行く
忙しいとか疲れている時こそ食べに行く：充実感でリフレッシュ
予約時：用途を言っておきたい(デートとか接待とか)、個室はテーブルか座敷か、お土産
/// フロイト vs ユング
フロイトが考えたのはこういうことだ。人間は誰しも、自分でも知らない 「心の秘密」をもっている。世の中には、不幸にも、なぜだかわからないうちに心や体の調子が悪くなり、しかもそのせいで周りとの人間関係までぎくしゃくしてしまっているような人がいる。そういう人の多くは、この「心の秘密」のせいで不幸になっている。
フロイトは、この秘密の在りかを「無意識」と呼んだ。
自分にも分からない 「心の秘密」などというものができてしまうの は、もとはといえばこの「話すこと」に原因があるのだと言ってよい。フロイトは、「無意識」をつくる心の働きを「抑圧」と呼んだが、これは「話すこと」を抜きには考えることが できないメカニズムである。つまり、あることを言わずに別のことを言う、ということではじめて、なにかが外へと追い出される、ということになるのである。
ときどき、精神分析 (まがい)の本を読んでいると、人間に心の病をもたらす根本的な問題は 「人間の本能が壊れている」ことだ、などという説明に出会うことがある。こうした考え方 は、精神分析の立場からすると、まったくの的外れだと言わねばならない。人間が「ことば」というものを話すようになった瞬間から、自らの本能的現実とはまったく異なる次元の「現実」に、すなわち、まさに「言語によって生み出される現実」に、捕らえられてしまうということ、そのことこそが重要なのだ。
言語の働きにのっとって話すことが「無意識」をつくり、また逆に「無意識」を探す道すじを与えてくれるのだとすれば、およそ人間の活動の及ぶあらゆる領域において、「無意識」が存在し、「無意識」が探求されうることになる。だからフロイト以後、文学も、人類学も、政治学も、社会学も、文学作品の中にも、未開社会の畑の中にも、政治的言説の中にも、はたまた社会構造そのものの中にも、「無意識」は存在するし探求されるようになった。
フロイト：チェコ、年子、ユダヤ改修派（ユダヤとして被差別、隣国ナチスとの関係）
ユング：ゲルマン系スイス、父プロテスタント牧師名士、母シャーマン家系
抑圧・トラウマを意識化すると神経症が治る。カタルシス→意識化していない、知らないことは怖い
抑圧＞無意識＞神経症（神経症だけでなく無意識に入り込む：夢・失錯行為・機知に反映）
心の構造論
イドesリビドー：快感原則
自我ego：健全
超自我super ego：無意識な躾（破ると後悔や罪責感）
エディプスコンプレックス：母好き父嫌いな息子
エレクトラコンプレックス：父好きな葉は嫌いな娘
劣等感を意味するのはコンプの一種でコレ、劣等複合（inferiority complex）
全ての他人よりも不足している、劣っているという信念から劣等感が生じ、極端な内気、自己隔離、社会的従順などが発生
死の欲動・影←対抗するには自我（健全）の強さが必要
駄目男に惹かれる＞快感（受動な不快を能動的に置換して和らげようとしている）
ヌーメン性：聖性が作用し自身が支配される
ニヒリズム：虚無主義、絶対的な価値がなくなる
脳科学の知見
思考）外部を知覚し判断
感情）内的寛容や内的欲求を抑圧し評価
情動）検索、のっとり、恐怖、パニックの少なくとも４つ
力動：反対方向に動くエネルギーの葛藤
愛情と攻撃性、欲望と禁
転移：患者が分析家に愛情や憎しみ等の感情を向ける、逆に分析家が患者に感情を向けると逆転移
解離：ヒステリーから別人格が現れる
(ヒステリー：強い感情があり意識から追い出されている記憶)
自由連想法：自由に話し無意識に閉じ込められた記憶を蘇らせる
催眠術：意識は眠らせるが無意識に話し掛け暗示を掛ける、これで支配できる
幼児期の性的トラウマが思春期以降にヒステリーとして現れる
夢：願望充足（あくまで無意識の。だがかつて意識から追放された欲望）
睡眠自体を守る行為の場合もある
圧縮＋移動＋抵抗の検閲
イドとエゴとスーパーエゴが夢を歪めているのを探る
夢により意識と無意識を近づけたと言える
子供の夢：強い歪曲や検閲がなく、また抑圧や記憶が少なく欲望成就そのままが多い
大人の夢：遠い記憶/複雑な葛藤/幼年期の記憶で圧縮移動されて分かりにくい
現実と欲望の葛藤→間違い/度忘れ/ヒステリー/脅迫神経症/夢で成就
プライベートで退行し抑圧を解放しバランスを取っている
（フロイト
夢や症状は個人史の中で探られるべき
脅迫症状には愛憎の葛藤や性的トラウマがある
夢には無意識に抑圧された願望が現れる
無意識は自我が受け入れられないものを放り込むゴミ箱のようなもの
自我は意識の中心、無意識の中に抑圧された衝動や感情が神経症の原因
神経症の原因は幼少期にある
（ユング
夢や症状は集合的無意識に根差す原初的なイメージとも比較対象すべき
物語が重要であり人の苦悩や背景を明らかにする
無意識は意識を補償するもので夢は無意識からのメッセージ
無意識はもっと創造的で植物にすら通底する将来的な層がある
意識と無意識からなる心の中心には自己（セルフ）がありこれを実現することが人生の目標
神経症の原因は現在にある、神経症の人こそ自己実現の可能性をもつ
（オレ
無意識の願望が幼稚な場合は折り合いがつかず問題だな
夢の定型変形
塔/ペン：ちんこ
鞄/洞窟：おまんちょ
王/王妃：両親
小動物：子供/兄弟
言葉遊びで別の言葉に置き変えらる
夢を他人に話す前提＞転移者(分析家)が夢に含まれている
前頭法：頭を叩きながら治療者が語り掛ける
自由連想法：頭に浮かんだことをそのまま語らせる
不安=内的、恐怖：外的、体内：楽園
不安の原型は出産外傷で分離、孤独、見捨てられ
神経症は無知に押し込まれている
暗示法は信頼関係＝転移が必要で危険＞フロイトは自由連想法に変えた
フロイト＝性欲、子供においては愛着・依存が
男女間の結合だけでなく、創造・欲求・生命力の源泉・活力
人間は性欲を学習するので間違いや失敗が起こりやすい
男:エディプスコンプ(母に恋し父を憎む)→去勢を連想→断念し父を真似→超自我→(拗らせ)性同一性
女:エディプスコンプ(母を愛す)→ちんこがない→劣っている→母を嫌悪→父に憧れ→他男と恋愛→(拗らせ)変な恋愛、ユング派はエレクトラコンプレックスという
肛門期：トイレ成功/失敗の躾＞SMに発展
ナルシシズム：性的エネルギーを自己に(自己保全)
防衛機制：抑圧(嫌な事は無責任化)、否認(認めない)、分離(感情を切り離し他人事)
防衛機制：同一化、反動形成(嫌なのに丁寧)、投射(被害妄想など)、合理化(知性化：言い訳)、昇華(虐めをスポーツ)
死への欲動(タナトス)：正か生き死に、外部とすると他者攻撃となる、あるいは超自我(躾)
生の欲動(エロース)：
戦争＝攻撃的欲求
宗教＝幼児は親に守ってもらいたい欲望(幼児神経症的)
芸術＝幼児期に抑圧された性的欲望を形を変え昇華
性欲・攻撃性・エディプスコンプを転換→仕事/スポーツ/絵/戦争/文学
ユング：心がどこへ向かおうとしているか？心は過去から未来へ発達を続けようとする
フロイト：過去(幼児期)>性的エネルギー
カレン、ホナイ：神経症は性欲でなく文化的要因=対人関係と基底不安（幼児期/孤独で無力)
アルフレッドアドラー：権力闘争/体力知力を求める、劣等感が神経症に
子供の人格形成：親は子供の世界に入るべきでない、自分で世界を発見すべき
幼児の人格形成：母が外部との緩衝になり、受け取れるものだけ選択し赤ちゃんに返すといい
ラカン：
想像界(鏡像)：ナルシシズムと攻撃性で事故や他人を形成する領域
象徴界：人を人と形成する言語の領域=法
現実界：死の欲動の領域
男性の去勢不安、女性のペニス羨望＞精神分析治療で乗り越えるのが難しい
自我心理学：自我を強くし適応能力を高める(無意識を長期間分析する必要がなくなる
認知行動療法：無意識にアプローチしないプラグマティックなトレーニング療法
例）ゴキブリ怖い＞映像を見て慣れる等(パブロフの犬的)
ニューロサイエンス：心の現象も脳内化学物質プロセス
心理学
ヴント：要素主義-構成主義-意識内容の考察
ワトソン：行動主義 S(刺激)-R(反応)
ヴェルトハイマー：ゲシュタルト心理学=形態(似てるものをグループしがち)
上の2つの反応観察に反論し全体性に光を当て解明しようとする、心は要素に分解できず部分からは導くことは不可
フロイト：精神分析
=======
枢軸 axis/pivot
国際関係のうえで親密な友好関係にあり、共同行動をとる国々。ナチス・ドイツ、ファシストのイタリア、軍国主義の日本。ムッソリーニがローマとベルリンを結ぶ垂直線を枢軸として国際関係は転回すると演説して有名に。ひっくり返すの暗喩。
直喩simile：～のような「雪のような肌」
暗喩＝隠喩metaphor：例えが隠されている「檻の中のライオン」
換喩metonymy：連想できる代替の語「白衣の力で治す」
Posted by funa : 04:17 PM
| Column
| Comment (0)
| Trackback (0)
September 2, 2022
Overtone
音は複数の成分音の集合で、そのうち最も振動数が少なく高さを決定する音を基本音fundamental tone。
Posted by funa : 02:54 AM
| Column
| Comment (0)
| Trackback (0)
July 24, 2022
Docker
どこでビルドしてもデプロイしてもImmutableインフラ（不変の）なので変更したい場合はDockerfileの方を変える
コンテナはOS上のDockerEngine上に配置する（コンテナは複数配置できる、Dockerfileさえあれば再現可）
DockerfileでなくてもDockerイメージでもいいが、Dockerは可搬性をもたらすのである
docker container run --name コンテナ名003 -d -p 8083:80 イメージ名httpd
■仮想NW
コンテナ間をつなぐ（ネットワークタグ名で紐づける感じ）
１）ブリッジネットワーク（デフォルト
同一の Docker Engine 上のコンテナ が互いに通信をする場合に利用する
デフォルト：
全てのコンテナ間をリンクする操作が必要
コンテナ間の通信は IP アドレスで
●(コレ使う)ブリッジネットワークを定義し作成：
相互通信は同じネットワークを割り当てるだけ
コンテナ間でDNS解決される
ネットワークでコンテナは隔離され隔離度が上がる
２）オーバーレイネットワーク
異なる Docker Engine 上のコンテナ が互いに通信をする場合に利用
docker network create ネットワーク名net001
↓
docker container run --name mysql001 -dit --net=net001 ～～～ イメージ名mysql
docker container run --name wordpress001 -dit --net=net001 -p 8085:80 -e WORDPRESS_DB_HOST=mysql001 ～～～ イメージ名wordpress
Docker仮想NW一覧
docker network ls
仮想NWの確認
docker network inspect net001
コンテナ間はservice_nemeで通信し、コンテナ名ではない
http://unco-sv:8000 で通信できる
各コンテナで同番ポートを使っていても問題はない
docker info プロキシ等が確認できる
.docker/config.json でプロキシやプロキシを使わないnoProxyを設定
■停止
docker stop コンテナ名
docker rm コンテナ名
docker network rm ネットワーク名
■コピー OS⇔コンテナ
docker cp コピー元 コピー先
例）docker cp /home/a.txt コンテナ名:/app/
■ボリュームのマウント
データをコンテナ内に置くとコンテナが消えるとデータも消えてしまう
永続化１）ボリュームマウント：DockerEngine上
永続化２）バインドマウント：OS上
永続化３）一時メモリマウント：（tmpfs）
■バインドマウント
docker volume create ボリューム名vol001
docker run --name コンテナ名httpd001 -d -p 8080:80 -v /home/a:/usr/local/apache/htdocs イメージ名httpd （OS側パス:コンテナ側パス、コンテナ側のパスをどこにすべきかはDockerイメージのドキュメントを見よ）
docker volume inspect vol001 （確認できる）
docker volume rm vol001
ホストディレクトリ共有ともいう
コンテナはrootで動作しているものが多く
ホスト共有しているDir/Fileにコンテナから変更するとrootで変更しPermissionが変わるそのためホストディレクトリ共有は本番に向かない
■ボリュームマウント
ちょい面倒らしいのでバインドマウントでいいのでは？
docker volume create ボリューム名vol001
docker run --name コンテナ名httpd001 -d -p 8080:80 -v ボリューム名vol001:/usr/local/apache/htdocs イメージ名httpd （OS側パス:コンテナ側パス）
docker volume inspect vol001 （確認できる）
docker volume rm vol001
Dockerボリューム共有ともいう
コンテナが削除されても明示的に消さない限り保持される
永続化したいパスを指定してマウントできる
（通常コンテナ内で作成されたデータは永続化しない）
■揮発的データを退避
docker cp コンテナ名:ファイルパス ホスト側退避パス
docker cp test-db-a:/opt/test.txt /tmp/config
消えるファイルをホスト側に退避したいときのコマンド
■ボリュームマウントの確認やOS側にバックアップ
アプリコンテナとは別のshellコンテナを用意してlsしたりtar.gz等する
Apacheコンテナ <-> vol001 <- Linuxコンテナ -> vol002バックアップ
マウントを2つ（DockerEngine上のマウント、OS上のマウント）
tar.gzコピーでDockerEngine上の指定フォルダにコピーするが其れはOS側にもマウントされている、最後のドットも要る
イメージは軽量Linuxのbusyboxを使用
docker run --rm -v vol001:/usr/local/apache/htdocs -v /home/b:/tmp busybox tar CXvf /tmp/bjk.tar.gz -C /usr/local/apache/htdocs .
■ログ
docker logs コンテナ名
docker logs -f コンテナ名 追従確認
docker exec -t コンテナ名 /bin/bash ログファイル等はこれで入り確認
■Appコンテナ（PHP)
docker container run \
--name app \ コンテナにappと名付る
--rm \ コンテナ停止時に自動削除
--detach \ バックグラウド実行
--interactive \ 対話可能なセッションに
--tty \ コンテナとのTTY接続しコマンド出力可
--mount type=bind,src=$(pwd)/src,dst=/src \ osにバインドマウント
--publish 18000:8000 \ ポートマッピング
--network docker-sample-network \ 仮想NWに割り当て
docker-php:app \ Dockerイメージの名前とタグ
php -S 0.0.0.0:8000 -t /src コンテナ内で実行するコマンド
※永続化バインドマウントos上
ホストマシンのディレクトリをコンテナ内のディレクトリにバインドマウント。ホストマシンのカレントディレクトリ（$(pwd)）の"src"ディレクトリが、コンテナ内の"/src"ディレクトリにマウントされます
※ポートマッピング
-p, --publishがコンテナのポートをホストマシンに公開するオプション
ホストマシンの18000ポートを通じてコンテナの8000ポートにアクセスさせる
ブラウザからhttp://localhost:18000 でphpにアクセス
※起動コマンド
PHPのビルトインウェブサーバを起動し、IPアドレス "0.0.0.0" およびポート "8000" でリクエストを受け付け、コンテンツを"/src"ディレクトリから提供します
■コンテナの詳細情報の確認
docker container inspect app
■DBコンテナ(MySQL)
docker container run \
--name db \
--rm \
--detach \
--platform linux/amd64 \
--env MYSQL_ROOT_PASSWORD=rootpassword \
--env MYSQL_USER=hoge \
--env MYSQL_PASSWORD=password \
--env MYSQL_DATABASE=event \
--mount type=volume,src=docker-db-volume,dst=/var/lib/mysql \
--mount type=bind,src=$(pwd)/docker/db/init.sql,dst=/docker-entrypoint-initdb.d/init.sql \
--network docker-sample-network \
--network-alias db \
docker-db:db
※仮想NWでのエイリアス名
dbと名付ける
■コンテナの疎通の確認
$ docker container exec --interactive --tty app ping db -c 3
appコンテナがdbに疎通できるかping
■アプリ
/// BANGBOO BLOG /// - GCP script 下の方に記載あり
■Dockerfile
ビルドしてイメージを作成
FROM イメージ名
COPY コピー元パス コピー先パス
RUN Linuxのコマンド
ENTRYPOINT イメージを実行するときのコマンド
CMD コンテナ起動時に実行する規定のコマンドを指定
例えばこのコマンドを実行するCMDは
$ go run /echo/main.go
↓空白で分割し配列化しCMD化される
CMD["go", "run", "/echo/main.go"]
ただCMDは下記のように実行中に上書き指定ができ echo yayの実行となる
docker container run $(docker image build -q .) echo yay
ONBUILD ビルドが完了したときに任意の命令を実行する
EXPOSE 通信を想定するポートをイメージの利用者に伝える
VOLUME 永続データが保存される場所をイメージ利用者に伝える
ENV 環境変数を定義する
WORKDIR RUN/CMD/ENTRYPOINT/ADD/COPYの際の作業ディレクトリ
SHELL ビルド時のシェルを指定
LABEL 名前やバージョンや制作者情報等を設定
USER RUN/CMD/ENTRYPOINT実行するユーザやグループを設定
ARG docker buildする際に指定できる引数を宣言
STOPSIGNAL docker stopの際にコンテナで実行しているプログラムに対して送信するシグナルを変更する
HEALTHCHECK コンテナの死活確認をするヘルスチェックをカスタマイズする
Dockerセキュリティベストプラクティス トップ20：究極ガイド社内のDockerfileのベストプラクティスを公開します│FORCIA CUBE│フォルシア株式会社RUN adduser -D myuser && chown -R myuser /myapp
（-Dはデフォルト設定で追加している、-Rは指定dir以下を再帰的に所有権変更）
USER myuser
（以降のRUNやENTRYPOINT等のINSTRUCTIONを実行するユーザを指定）
FROM ubuntu:latest
RUN mkdir /app
# "appuser" という専用のグループとユーザーを作成（ログイン不要のシェル設定）
RUN groupadd -r appgroup && useradd -r -s /usr/sbin/nologin -g appgroup appuser
WORKDIR /app
COPY . /app
# ユーザー権限を変更（アプリケーションディレクトリの所有者を "appuser" に設定）
RUN chown -R appuser:appgroup /app
# 最小特権ユーザーで実行
USER appuser
# アプリケーションの実行コマンド
CMD ["node", "index.js"]
Dockerfileの作り方を考え直したらすごく効率が上がった。 (zenn.dev)■ビルドでイメージを作成
Dockerfileや材料ファイルのあるフォルダパスを最後に指定、-tはタグでイメージ名
docker build -t img_httpd001 ./
ビルド後にdocker runが必要
docker container run -d --name cnt_httpd001 -v ${pwd}:/app img_httpd001:latest
↓これが便利
docker container run -rm --name cnt_httpd001 -v ${pwd}:/app img_httpd001:latest
■commitでコンテナからイメージを作成
コンテナにexecで幾つかインスコする操作をしてからイメージにする等ができる
docker commit httpd001 img_httpd001
■コンテナ/イメージはDockerEngine上から移動できない
saveするとファイル化され、できるようになる
docker save -o save_img_httpd001.tar img_httpd001
ファイルからイメージとして取り込みたいときはdocker load
ファイル化せずにパブリックならDocker hubへ登録してもよい、プライベートレジストリを作ってもよい
その中にそれぞれリポジトリを持つ > docker push レジストリ/リポジトリ名:バージョン
■コンテナに命令する
2つの方法がある
１）docker exec → docker container execに変わった
起動中のコンテナ内でコマンドを実行する
docker container exec [option] <container> command
ファイルを見る
docker container exec ubuntu1 cat ~/hello.txt
コンテナに接続してbashを使う
docker container exec --interactive --tty ubuntu1 bash
２）docker run に引数を付ける→ソフトウェア(apache)が動いていない状態になり改めてdocker startが必要
docker exec -it コンテナ名httpd001 /bin/bash
apt install mysql-server など対話でコンテナにインスコできる
exit 抜ける
■Docker compose
docker runコマンドの集合体、コンテナ等作って消すだけ（k8sはコンテナ等を管理する）
以前はdocker-composeコマンドで別ツールだったが今は統合済み
フォルダに1つだけdocker-compose.yml
基本はdocker runを実行せずにdocker composeしたい
手順は、１）Docker run方法で一応の検討>２）docker-compose.ymlの記述>３）docker composeコマンドの実行
docker run~~に対するdocker-compose.ymlとdocker composeコマンド の対比
１）docker run --name cnt_wordpress001 -dit --net=net001 -v wordpress001vol2:/var/www/html -p 8080:80 -e WORDPRESS_DB_HOST=mysql001 -e WORDPRESS_DB_NAME=wpdb001 -e WORDPRESS_DB_USER=wpu001 -e WORDPRESS_DB_PASSWORD=my-secret-pw wordpress
↓
２） docker-compose.ymlの記述
version: "3"
services:
cnt_wordpress001:
depends_on:
- cnt_mysql001
image: wordpress
networks:
- net001
volumes:
- wordpress001vol2:/var/www/html
ports:
- 8080:80
restart: always
environment:
WORDPRESS_DB_HOST=mysql001
WORDPRESS_DB_NAME=wpdb001
WORDPRESS_DB_USER=wpu001
WORDPRESS_DB_PASSWORD=my-secret-pw
cnt_mysql001:
image: mysql:5.7
networks:
- net001
volumes:
- mysql001vol1:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD=my-root-pw
MYSQL_DATABASE=wpdb001
MYSQL_USER=wpu001
MYSQL_PASSWORD=my-secret-pw
networks:
net001
volumes:
mysql001vol1:
wordpress001vol2:
/// restartの設定値（コンテナが停止した時にどうするか？）
no ＝何もしない
always ＝必ず再起動する
on-failure ＝プロセスが0以外のステータスで終了したときは再起動する
unless-stopped ＝停止していたときは再起動しないがそれ以外は再起動する
Bashで終了ステータスよる条件分岐 | Codebase Blog ※bashは前に実行されたコマンドの終了ステータスは「$?」で取得できるが慣習的にコマンドが正常終了した場合は0を返す
/// その他の定義項目
command ＝起動時の規定コマンドを上書きする
entrypoint ＝起動時のENTRYPOINTを上書きする
env_file ＝環境設定情報のファイルを読み込む
他 container_name / dns / eternal_links / extra_hosts / logging / network_mode etc.
３）docker compose コマンド
up=イメージDL、コンテナ/nw/volの作成・起動
down=コンテナとnwの停止と削除、volとイメージは残る
stop=削除せず停止のみ
docker compose -f /home/a/docker-compose.yml up -d
docker compose up -d --scale unco001=3 （コンテナ名はput-folder-name_unco001_1, put-folder-name_unco001_2, put-folder-name_unco001_3になる）
-f ファイルの場所（省略でカレントパス）
-d バックグラウンド実行
--build コンテナ開始前にビルド
--no-build イメージが見つからなくてもビルドしない
-t コンテナ停止のタイムアウト（デフォ10S）
--force-recreate 設定やイメージに変更が無くてもコンテナを再生成
--no-create コンテナが存在していれば再生成しない
--abort-on-container-exit コンテナが一つでも停止したら全てのコンテナを停止
--remove-orphans 定義ファイルで定義されていないコンテナを削除
--scale 同じコンテナを複数作る
docker compose -f /home/a/docker-compose.yml down
--rmi {all | local} 破棄後にイメージも削除、localの時はimageにカスタムタグが無いイメージのみを削除
-v volumesに記載されているボリュームを削除、但しexternalの指定を除く
--remove-orphans 定義ファイルで定義されていないコンテナを削除
docker compose -f /home/a/docker-compose.yml stop
コンテナを停止
■Docker composeはコンテナ名を勝手につける
docker-compose.yml内は下記の通り、DockerEngine上のコンテナ名は変わるがdocker-compose.yml内のコンテナ名は変わず指定できる
services:
unco001
～
unco002
namespaceで分離し
ファイル構造、ユーザーID、グループID、コマンド、ライブラリなど諸々を
ラップしコンテナ化し(単一の)プロセスとして動く
↓
Dockerがやっている仕事は少ない
区切ってコンテナ
それら仮想ネットワークで繋ぐ
ボリュームの永続化
Dockerfileでイメージからイメージを作成
Docker composeでdocker runを記述
docker execでコンテナを操作
etc.
Posted by funa : 03:46 AM
| Web
| Comment (0)
| Trackback (0)
May 18, 2022
LPIC
Level1 Ver4.0
■システムアーキテクチャ
周辺機器のon/offや起動ドライブ検索順序はBIOS/UEFI
/proc以下のファイルによりカーネルが認識しているデバイスを確認できる
/dev以下にはデバイスファイルがある
USBはホットプラグデバイス
lsusbでUSBデバイスの情報、lspciでpciデバイスの情報を確認できる
modprobeコマンドでデバイスドライバをロード
起動時にカーネルが出すメッセージはdmesgで表示
SysVinitのシステムでは/etc/inittabでデフォルトのランレベル設定
0：停止、1：シングルユーザモード、5：マルチユーザモードGUI、6：再起動
ランレベル移行はinitやtelinit
systemdのシステムはsystemctlでサービス管理
shutdownでシステム停止や再起動
■インスコとパッケージ管理
インスコにはルートパーティション/とスワップ領域が必要
中大規模では/varや/homeと/は別パーティションが良い
/varはログやメールデータ
/homeは各ユーザのホームディレクトリで肥大化しやすい
スワップ領域は物理メモリと同程度から2倍を確保
GRUBのインスコにはgrub-install
GRUB Legacyの設定ファイルは/boot/grub/menu.lst
GRUB 2の設定は/etc/default/grub、grub-mkconfigを実行すると設定ファイル/boot/grub/grub.cfgができる
共有ライブラリはld.soによってリンクされる
実行ファイルが必要とするライブラリはlddで確認
ld.soが参照する/etc/ld.so.cacheは/etc.ld.so.confを元にldconfigで作成
Debianパッケージ管理はdpkgやAPTツールで、apt-get、apt-cache、aptitudeがある
APT設定ファイルは/etc/apt/sources.list
RPMパッケージ管理はrpmやYUM
rpmでパッケージをインスコするには-i、アップグレードには-Uもしくは-F、アンインスコには-eオプション
rmp -qはパッケージ情報の参照
YUMレポジトリ設定は/etc/yum.repos.dディレクトリ以下のファイルで
■GNU
変数名=値 でシェル変数を設定
echo $変数名 で変数の中身を確認できる
unsetで変数を削除
exportでシェル変数を環境変数に
環境変数を一覧 env や printenv
環境変数とシェル変数を一覧 set
環境変数PATHでコマンドの検索パスを定義
複数コマンドを連続実行は;で区切る
直前のコマンドが成功したときのみ次コマンド実行 &&
失敗した時のみ実行は ||
'や"の囲みは文字列として、`の囲みはコマンドと解釈
"や`の囲みの中は変数展開されるが、'ではされない
historyでコマンド履歴表示
manでマニュアル参照、1:ユーザコマンド、5:ファイルfmt、8:システム管理cmd
属性を保持したままコピーは cp -p
移動先で上書きしたい場合は cp -f、あるいは mv -f
ディレクトリ作成で必要な親ディレクトリを作る場合は mkdir -p
サブディレクトリを含めて削除 rm -r
file でファイルの種別を確認できる
シェルでワイルドカードが使える
. 任意1文字
* 直前の文字の0回以上繰り返し
[] いずれか1文字
[a-c] aからcの範囲
[^ab] aとb以外
^ 行頭
$ 行末
\ エスケープ
+ 直前の文字の1回以上の繰り返し
? 直前の文字の0回もしくは1回の繰り返し
| 左右いずれかにマッチ
コマンドの出力を別コマンドの入力化やファイル格納するにはパイプやリダイレクト
tee 標準入力をファイルに格納し同時に標準出力に出す
ファイルの表示・連結は cat
バイナリファイルを8進数法事するには od
テキストファイルの先頭表示 head、末尾表示 tail、-nで行数
tail -f でファイル末尾を継続監視
テキストファイルの列の取り出しや連結 cut や join や paste
trは文字列を置換
uniqは重複する行を1行にまとめる
xargsで標準入力から受け取った文字を引数にし与えられたコマンドを実行
grepやsedで正規表現を使う
■ファイルとプロセスの管理
gzip, bzip2, xy はファイル圧縮
unzip, bunzip2, xz(unxz)はファイル解凍
tar, cpio はアーカイブ作成・展開
chown ファイルやディレクトリの所有者設定
ユーザは必ずどこかのグループに登録しなければならない
一般的にはユーザ名と同じグループ名でメイングループとして登録していることが多い
ユーザがメイン以外で登録しているグループ。複数登録できる
ファイルやディレクトリの作成時点では所有ユーザ＝作成ユーザのメイングループがそのまま所有グループとなる
所有者をuser2に変更
chown user2 test.txt
所有者をuser2にグループをgroup2に変更
chown user2:group2 test.txt
：から書くとグループだけ変更
chown :group2 test.txt
ファイルのグループの調べ方
ls -l
chgrp は所有グループ変更
chmod ファイルやディレクトリのアクセス権変更
SUIDやSGID適用のプログラムは実行ユーザに関係なく所有者or所有グループの権限で実行スティッキービットを設定したディレクトリは自分が所有するファイル以外削除不可
アクセス権
所有者/グループ/その他
r読み 4
w書き 3
x実行 1
ナシ 0
アクセス権はファイルは666から、ディレクトリは777からumask値を引いた値
ln でハードリンク、ln -s でシンボリックリンク作成
ps, pstree, pgrep でプロセス参照、top でシステム状況を一定間隔で表示
kill, killall, pkull でプロセス終了・再起動等
1:HUPハングアップ、2:INT割り込みctl+c、9:KILL強制終了、15:TERM終了デフォ、18:CONT再開、19:STOP一時停止
コマンドラインの最後に&でバックグラウンド実行
jobs でシステム上のジョブを確認
free でメモリの利用状況を確認
uptime でシステムの平均負荷を確認
nice でプロセスの実行優先度を指定、変更には renice
ナイス値-20-19で実行優先度を指定
■デバイスとLinuxファイルシステム
fdisk, gdisk, parted でパーティション作成
mkfs でファイルシステムを作成
ext2, ext3, ext4ファイルシステムを作成するには mke2fs
mkswap でスワップ領域を作成
df でファイルシステムの利用状況を確認
du でファイルやディレクトリを含めたサイズを確認
fsck, e2fsck でファイルシステムの整合性チェックや修復
ext2, ext3, ext4ファイルシステムのパラメータ設定は tune2fs
mount でファイルシステムのマウント、解除は umount
継続利用や頻繁利用のファイルシステム情報は /etc/fstab に格納
ディスク利用容量の制限はディスククォータを使う、ハードリミット、ソフトリミット、猶予期間を設定できる
find, locate でファイル検索、locateはあらかじめ準備されたDBに基づいて検索
which, whereis でコマンドのフルパスを表示
■シェル、スクリプト、データ管理
コマンドの別名設定は alias、設定解除は unalias
関数の定義はfunction、定義済み関数を表示は declare -f
bashのログイン時に全ユーザで実行される/etc/profile、ユーザ毎は~/.bashrc
条件判定するには test
直前に実行したcmdの戻り値は$?で確認できる、正常終了:0、それ以外はそれ以外の値が多い
条件分岐 if-then-else-fi、case-in-esac
繰り返し for-in-do-done、while-do-done
seq は連続した数値を生成する
read は標準入力から文字列を読み込んで変数に代入する
■ユーザインターフェイスとデスクトップ
Xサーバは入出力管理を担当、Xクライアントはユーザアプリに対応
Xの設定はxorg.confでセクションごとに記述する、セクション：
ServerLayout＝入出力デバイスとスクリーン
Files＝フォントやカラーDBファイルのパス
InputDevices＝キーボードやマウスなど入力装置の設定
Monitor＝モニター設定
Device＝ビデオカードの設定
Screen＝ディスプレイの色深度や画面サイズ設定
Xサーバとクライアントが別コンピュータの場合の設定
１）Xクライアントで環境変数DISPLAYにXサーバを指定
２）XサーバでXクライアントからのアクセスを受け付けるよう xhost で設定
xwininfo はウィンドウの情報を表示する
ディスプレイmgrはユーザ認証やシェルの起動で XDM, GDM, KDM, LightDM等
ウィンドウmgrはXの外観で twm, fvwm, enlightenment, Mutter, Fluxbox, Compiz, KWin等
キーボードのアクセシビリティには スティッキーキー、スローキー、バウンスキー、トグルキー、マウスキー等
■システム管理１
ユーザ情報は /etc/passwd に格納
シャドウパスワード利用時はパスワード情報は /etc/shadow に格納
グループ情報は /etc/group に格納
ユーザ情報の追加 useradd
ユーザ情報の削除 userdel
ユーザ情報の変更 usermod
グループ情報の追加 groupadd
グループ情報の削除 groupdel
グループ情報の変更 groupmod
ユーザパスワードの設定 passwd
useradd時は /etc/skel以下がユーザのホームdirにコピーされる
定期的なジョブ実行には cron
ログインユーザで設定・実行される（sudo crontab -eでRoot実行という意味）
システムが起動していなかった時のcronジョブは anacron で実行
anacron の設定は /etc/anacrontab
1回限りのジョブ予約は at 日時cmd、確認は atq あるいは at -l
ジョブの削除は atrm あるいは at -d
ロケール確認は locale
文字コードを変換 iconv
タイムゾーンは /usr/share/zoneinfo 以下にあり /etc/localtime にコピーする
システムのタイムゾーンは環境変数 TZ、/etc/timezone に設定する
■システム管理２
システムクロックを設定するには date
ハードウェアクロックは hwclock
NTPサーバに問い合わせシステムクロックを設定するには ntpdate
NTPサーバプロセスは ntpd、設定ファイルはntp.conf
syslogの設定は etc/syslog.conf、ファシリティ、プライオリティに応じたログの出力先を指定
rsyslogの設定は /etc/rsyslog.conf
logger でログの生成ができる
ログローテーションは logrotate、設定は /etc/logrotate.conf
メールサーバMTAには Postfix, sendmail. qmail, exim等
メールアドレスの別名は /etc/aliases で定義し newaliases で有効にする
メールの転送は ~/.forward で設定する
メールキューの状況は mailq で確認
印刷は lpr で行う、 -# オプションで印刷部数
プリントキューの状況確認は lpq
プリントキューの印刷要求を削除するには lprm
■ネットワークの基礎
IPv4は32ビットで8ビットずつを10進数に変換した表記を使う
IPv6は128ビット
サブネットマスクはネットワーク部とホスト部の境界を表す
IPアドレスとサブネットマスクの論理積がネットワークアドレス
プライベートアドレス クラスAは10.0.0.0～10.255.255.255 （10.0.0.0/8）
クラスBは172.16.0.0～172.31.255.255 （172.16.0.0/12）
クラスCは192.168.0.0～192.168.255.255 （192.168.0.0/16）
サービスとポート番号の対応は /etc/services に記載 Well-Known-Port：0-1023
TCP20：FTP（データ）
TCP21：FTP（制御）
TCP22：SSH
TCP23：Telnet
TCP25：SMTP
UDP53：DNS
UDP67：DHCP（サーバ）
UDP68：DHCP（クライアント）
TCP80：HTTP
TCP110：POP3
TCP123：NTP
TCP443：HTTPS
TCP587：SMTP(サブミッションポート）
IMAP overSSL：993
POP3 overSSL：995
ホストと通信ができるか ping
経由するルータ情報は traceroute や tracepath
ホスト名からIPアドレスは dig や host
ホスト名の確認や設定は hostname
ルーティングテーブルの確認や設定は route
ネットワークインターフェイスの設定や動作状況確認は ifconfig
有効化は ifup、無効化は ifdown
/etc/resolv.conf に参照先DNSサーバを設定する
ホスト名とIPアドレスの対応は /etc/hostsファイルに記述
名前解決の順序は /etc/nsswitch.confに設定
■セキュリティ
スーパーサーバ inted や xinetd は他のサーバプログラムに変わって要求を受けサーバプログラムを起動し常駐プロセスを減らすことでシステムリソースの節約をする
xinetd の全体設定は /etc/xinetd.conf、各サービスの設定は /etc/xinetd.d 以下
TCP wrapper等を利用しているアプリケーションの場合 /etc/hosts.allow や /etc/hosts.denyにアクセス制限を設定する
開いているポートを確認するには netstat, lsof, nmap
パスワードの有効期限を設定するには change
/etc/nologinファイルを作成しておくと一般ユーザはログインできない
su で他のユーザになれる
sudo でroot権限の一部を一般ユーザが利用できる
設定は visudo で /etc/sudoers ファイルに記録される
ユーザが利用できるシステムリソースを設定するには ulimit
OpenSSHはユーザ認証以外にホスト認証も行うセキュアな通信を実現
信頼できるホストのホスト鍵は ~/.ssh/known_hosts
公開鍵認証で利用する鍵ペアは ssh-keygen
scp で安全なファイル転送ができる
ssh-agent と ssh-add でパスフレーズを記憶させることができる
gpg で GnuPGの鍵管理やファイルの暗号化・複合ができる
=============
Level2 Ver4.0
■キャパシティプランニング
メモリやスワップの情報は top, free, vmstat
プロセス情報は top, ps, pstree
CPUの平均負荷(直近1分、5分、15分)は top, uptime
vmstat はメモリや仮想メモリの詳細な状態を継続的に監視
iostat はCPUの利用状況とディスクの入出力の情報を継続的に監視
NFSでは nfsiostat、CIFSでは cifsiostat で
sar で様々なシステム統計情報を確認
w でログイン中ユーザとそのプロセス情報を確認
netstat でネットワークの統計情報を確認
lsof で開いているファイルとポートを確認
システム監視ツールには collectd, Nagios, MRTG, Cacti等でWeb IFあり
■Linuxカーネル
カーネルバージョン確認は uname -r や /proc/version や /usr/src/linux/Makefile
カーネルモジュールは /lb/modules/`uname -r` dirにインスコされる
dirのパスは /usr/src/linux/Makefile で設定
カーネルモジュール操作は：
lsmod ロードされているモジュールをリスト表示
insmod モジュールをロード
rmmod モジュールをアンロード
modprobe 依存関係を解決してモジュールをロード、アンロード
depmod モジュールの依存関係情報を更新
modinfo モジュールの情報を表示
modprobe が利用するモジュールの依存関係情報はmodules.depファイルにあり depmod で更新可
カーネルの設定ファイルは .config
カーネル2.6以降は下記手順でカーネル再構築
make config | menuconfig | xconfig | gconfig
make
make modules_install
make install
初期RAMディスクを作成するには mkinitrd や mknitramfs
デバイスファイルは udev が動的に作成する
udev の設定ファイルは /etc/udev/rules.dディレクトリ以下にある
udevadm monitor で udevd をモニタできる
sysctl でカーネル設定を表示更新できる
dmesg で起動時のカーネルメッセージを確認できる
/proc ディレクトリ以下のファイルを通してカーネルが認識しているハードや実行中のプロセスやシステムリソース等の情報が分かる
/proc 以下の情報は lsdev, lspci, lsusb で表示
■システムの起動
BIOS->MBR->ブートローダ->カーネル->initの順で起動
initの設定は /etc/inittab 、書式は ID:ランレベル:action指示子:処理
ランレベルごとの起動スクリプトは /etc/rc.[0-6].dディレクトリにある
デフォルトで起動するサービスは chkconfig や update-rc.d で設定
起動プロンプトでカーネルやinitに渡すパラメータを指定できる
起動時に指定したパラメータは /proc/cmdline で確認できる
grub でGRUBシェルが使える
GRUB Legacyの設定ファイルは /boot/grub/menu.lst
GRUB 2の設定ファイルは /boot/grub/grub.cfg
GRUB 2の設定は /etc/default/grub に記述し update-grub を実行すると /boot/grub/grub.cfgが生成される
LILOの設定ファイルは /etc/lilo.conf
LILOの設定変更後は lilo よりMBRを更新する
SYSLINUX はFATファイルシステムからカーネルを起動する
ISOLINUXはISO09660ファイルシステムからカーネルを起動する
PXEはネットワークブートの規格
■デバイスとファイルシステム
マウント設定は /etc/fstab で行う、デバイス名にはUUIDやラベルも使える
カーネルがサポートしているファイルシステムは /proc/filesystems で確認できる
/etc/mtab には現在マウントしているファイルシステムの情報がある
/etc/mtab と /proc/mounts はほぼ同じ内容
mount -o remount でファイルシステムを再マウント、マウントオプションの変更に利用
tune2fs で ext2/ext3/ext4ファイルシステムの各種パラメータを表示・変更できる
blkid でデバイスのUUIDを確認できる
sync はディスクバッファ領域にあるデータをディスクに書き込む
mkswap でスワップ領域を作成できる
ファイルとしてスワップ領域を用意するには dd で任意のサイズのファイルを作成する
swapon でスワップ領域を有効化、 swapoff で無効化できる
swapon -s か /proc/swaps でスワップ領域を確認できる
ext2ファイルシステムを作成するには mke2fs あるいは mkfs -t ext2
ext3なら mke2fs -j あるいは mkfs -t ext3
ext4なら mkfs -t ext4
XFSファイルシステムを作成するには mkfs.xfs あるいは mkfs -t sfs
CD/DVD-ROMイメージの作成は mkisofs
ファイルシステムの整合性チェックには fsck あるいは e2fsck あるいは xfs_check
S.M.A.R.T.はハードディスク自己診断機能で smartdデーモンが情報収集する
smartctl で S.M.A.R.T.情報を表示
オートマウントの設定は /etc/auto.master とマップファイルで行う
■高度なストレージ管理
RAID0は冗長性が無いが高速
RAID1は冗長性があるがディスク容量は半減
RAID4やRAID5はパリティを使って冗長性を保つ
RAID4はパリティを専用ディスクに保存、RAID5はパリティ情報を分散
madadm でRAIDを構築・管理
/proc/mdstat でRAIDの状態を確認
物理ボリュームを作成するには pvcreate
ボリュームグループを作成するには vgcreate
論理ボリュームを作成するには lvcreate
スナップショットを利用するとアンマウントなしで lvcreate でバックアップができる
hdparm でIDEハードディスクのパラメータを設定
sdparm でSCSI/SATA/USBハードディスクのパラメータを設定
iSCSIストレージを利用するホストをイニシエータ、iSCSIストレージをターゲットと呼ぶiscsiadm はSCSI管理ユーティリティ
iSCSIストレージ内の論理ドライブ番号をLUNという
■ネットワーク
MACアドレスとIPアドレスの対応はARPキャッシュに保存され、arp で参照・設定できる
ネットワーク関連コマンドでは -n オプションで名前解決を抑制できる
tcpdump はNIC上のパケットをダンプ出力する
GUIのパケットキャプチャツールにはWiresharkがある
netstat はネットワークの情報を表示する
ルーティングテーブルは route で設定する
ip は ipconfig, arp, route といったコマンドと同等の操作ができる
nmap でポートスキャンやIPアドレススキャンができる
NIC間でパケット転送を行うには /proc/sys/net/ipv4/ip_forward の値が1である必要がある
■システムメンテナンス
tarボールは tar を利用して作成・展開する
configureスクリプトはシステム環境に応じたMakefileを生成する、多くのオプションの指定ができる
make はMakefileに記述された処理を行う、Makefileには各種ターゲットを設定できる、ターゲットにはinstall や clean などがある
バックアップには、フルバックアップ、差分バックアップ、増分バックアップなどの種類がある
バックアップなどに利用できるコマンドとして tar, cpio, dd, dump, restore, rsync などがある
mt でテープドライブを操作する
テープドライブを表すデバイスファイル /dev/st0 は巻き戻しあり、/dev/nst0 は巻き戻しなし
ネットワークバックアップツールには Amanda, Bacula, BackupPC などがある
ログイン直後に表示するメッセージは /etc/motd に記述する
ログイン時に表示するメッセージは /etc/issue に記述する
ネットワーク経由のログイン時に表示するメッセージは /etc/issue.net に記述する
バッチを適用するコマンドは patch で -R オプションでパッチの適用と取り消しを行う
■DNS
DNSサーバには、BIND, dnsmasq, djbdns, PowerDNSなどがある
DNSクライアントコマンドには、 dig, host, nslookup がある
BIND9は mdc で管理できる
/etc/named.confでは様々なオプションが指定できる
allow-query DNS問い合わせを受け付けるホスト
allow-recursion 再帰的な問い合わせを受け付けるホスト
allow-transfer ゾーン転送を許可するホスト
blackhole 問い合わせを受け付けないホスト
directory ゾーンファイルを格納するディレクトリ
forwarders 問合せの回送先DNSサーバ
forward forwardersの回送方法
max-cache-size 最大キャッシュサイズ
recursion 再帰的問合せを受け付けるかどうか
version バージョン表示
ソーンファイルのレコードは
SOA ゾーンの管理情報
NS ゾーンを管理するネームサーバ
MX メールサーバ
A ホスト名に対応するIPアドレス正引き
AAA ホスト名に対応するIPv6アドレス正引き
CNAME 別名に対応するホスト名
PTR IPアドレスに対応するホスト名逆引き
SOAレコードのメールは@を.に変更して指定する
ゾーンファイル内では@はゾーン名を表す
MXレコードではプリファレンス値が小さいものほど優先度が高くなる
NSレコードやMXレコードには別名を使わない
BIND9では dnssec-keygen でセキュリティ用のカギを作成できる
dnssec-signzone でゾーンに署名を行う
■Webサーバとプロキシサーバ
Apacheのメイン設定ファイルはhttpd.confだがディストリビューションによって異なる
DirectoryIndexディレクティブでインデックスページを定義する
ErrorDocumentディレクティブでエラーページを定義する
Aliasディレクティブでドキュメントルート外のコンテンツを参照できる
CustomLogディレクティブでログファイルを定義する、デフォルトのログファイルはaccess_logである
ErrorLogディレクティブでエラーログファイルを定義する、デフォルトのログファイルはerror_logである
UserDirディレクティブで公開するユーザのホームディレクトリを定義する
MaxClientsディレクティブで最大子プロセス数を指定する
apachectl でApacheを管理できる
基本認証を使ったアクセス制御でユーザとパスワード設定は htpasswd を使う
ダイジェスト認証を使ったアクセス制御でユーザとパスワードを設定するには htdigest を使う
.htaccessファイルでhttpd.confの設定を上書き、httpd.conf内のAllowOverrideディレクティブで上書きを許可する範囲を設定
AccessFileNameディレクティブで外部設定ファイルの名前を定義する
ApacheではIPベースのバーチャルホストと名前ベースのバーチャルホストを利用できる
SSLサーバ証明書はIPアドレスとドメイン名のペアに対して発行される
NginxはオープンソースのWebサーバ、リバースプロキシサーバである
Nginxの設定は nginx.confを中心とした /etc/nginxディレクトリ以下のファイルで行う
Squidの設定ファイルは squid.confであり、aclディレクティブと http_accessディレクティブでアクセス制御を設定する
■ファイル共有
Sambaユーザを作成するには smbpasswd, pdbedit を使う
パスワード変更には smbpasswd
ユーザ認識方法はsmb.conf のsecurityパラメータで指定
Sambaサーバがマスターブラウザになる優先度はOSレベルに基づく
OSレベルはsmb.confのoslevelパラメータで指定
testparm でsmb.confの構文をチェックできる
smbstatus でSambaに接続されているクライアントとオープンされているファイルを確認できる
nmblookup でNetBIOS名やマスターブラウザを照会できる
smbclient を使うとSambaクライアントとして共有リソースを利用できる
Microsoftネットワークの共有リソースをマウントするには smbmount
rpcinfo でRPCサービスの状況を確認できる
exportfs でエクスポート状況を表示したり/etc/exportsの変更を反映させたりできる
NFSサーバでエクスポートしているディレクトリを調べるには showmount を使う
■ネットワーククライアント管理
/etc/dhcpd.confで割り当てるIPアドレスの範囲を指定するには range 192.168.0.0 192.168.0.99; のように記述する
リース中のIPアドレス情報はdhcpd.leasesファイルに記録される
dhcrelayはDHCPリレーエージェントである
PAMの設定ファイルは/etc/pam.dディレクトリに配置されるが/etc/pam.confが使われることもある
PAM設定ファイルの書式は モジュールタイプ コントロール モジュールのパス 引数
requiredとrequisiteコントロールの違いは認証に失敗したときrequiredは同じタイプのモジュールの実行が全て官僚した時点で認証を拒否するのに対し、requisiteはすぐに認証を拒否する
LDAPエントリはLDIF形式でテキストファイルに記述できる
エントリを一意に識別する名前をDN（識別名）という
個々のエントリはいずれかのオブジェクトクラスに属する
ldapadd でLDAPエントリを追加する
ldapsearch でLDAPエントリを検索する
ldapdelete でLDAPエントリを削除する
ldapmodify でLDAPエントリの内容を変更する
ldappasswd でLDAPエントリに設定されるパスワードを変更できる
OpenLDAPサーバの設定ファイルは slapd.conf
slapadd でLDAPデータベースをリストアできる
slapcat で全てのエントリの情報をLDIF形式で出力できる（オフラインバックアップ）
slapindex でLDAPデータベースのインデックスを再構築できる
SSSDは識別サービス・認証サービスとの通信を管理しキャッシュをするデーモンである
■メールサービス
SMTPサーバには Postfix, exim, sendmailなどがある
メールボックスには1ユーザ1ファイルに格納されるmbox形式と1メール1ファイルに格納されるMaildir形式がある
Postfixのメイン設定ファイルはmain.cfである
postconf で設定パラメータを表示できる
postqueue -p でメールキューを確認できる
postqueue -f でメールキュー内のメール配送を直ちに試みる
/etc/aliases にはメールのエイリアスを設定する。別名指定方法は次の通り
user[,user..] ユーザのメールに配信
/path ファイルに追加
|command コマンドの標準入力へ
user@domain メールアドレスへ転送
:include:/path 外部ファイルを読み込む
/etc/aliasesの変更を反映させるには newaliases を実行する
procmail の設定ファイルは/etc/procmailrcと~/.procmailrc
/etc/procmailrcと~/.procmailrcのレシピの書式は次の通り
:0 [フラグ] [:ロックファイル]
* 条件式
アクション
Dovecotの設定は/etc/dovecot.confで行う
■システムセキュリティ
iptables でパケットフィルタリングを設定する
proftpd.confは ProFTPD の設定ファイルである
vsftpd.confは vsftpd の設定ファイルである
pure-ftpd.confは Pure-FTPD の設定ファイルである
/etc/ftpusers にはFTPログインアクセスを許可しないユーザを記述する
信頼できるホストのホスト鍵は ~/.ssh/known_hostsに格納される
公開鍵認証で利用する鍵ペアは ssh-keygen で生成する
~/.ssh/authorized_keysファイルには接続するユーザの公開鍵を登録する
scp で安全なファイル転送ができる
ssh-agent と ssh-add でパスフレーズを記憶させることができる
Snort はネットワークベースのIDSツール
Tripwireはファイルの改ざんを検知するIDSツール
OpenVASは脆弱性のチェックを行うツール
Fail2banはログから判断して攻撃を遮断するツール
nmap はポートスキャンを行うツール
開いているポートは netstat, lsof, nmap, fuser などのコマンドで調査
OpenVPNにはルーティング接続とブリッジ接続がある
OpenVPNサーバにはCA証明書、サーバ証明書、サーバ秘密鍵、DHパラメータを配置する
OpenVPNクライアントにはCA証明書、クライアント証明書、クライアント秘密鍵を配置する
OpenVPNサーバはUDPポート1194番を使用する
=============
SELinuxは事後防衛的な手段だ。もしサーバに侵入されたとしても、被害を最小限に抑えるための仕組みとなっている。そのため侵入事態を防衛できるものではない
redhat系
この辺は抑えておきたい、昔は無かっただけだと思うが
LVM（logical volume manager）
シェル変数をexportして環境変数
ルートログイン不可、警告文表示
プロセスの優先順位ナイス値
バックグラウンドジョブでログアウトしても実行
スーパーサーバ、TCPwrapperでプロセス省略
パケットフィルタリング、ルーティングテーブル(nat/forward)
SSHポート転送(popやftpでも可)
ver5でもそれほど変化がないのでは、systemdの強化辺りか？gitやdockerをカバーしたように思ったが？
=============
/etc
各種の設定ファイルの保存場所 hostsとか.confとか
バイナリファイルを置かないこと
/opt用の設定ファイルを置くために/etc/optを設けること
/opt
アプリパッケージ
/usr
各ユーザー共通利用のプログラムやライブラリが置かれるunix shared resouces
/var
ログやキャッシュ、再起動しても残り続ける
/etc/logrotate.confで1週間4世代等を設定
/sbin
システム管理者用bin
/etc/fstab マウント情報が記載されている
mount -a マウント情報を書き直すと全てマウントしなおす
■/varを別ディスクにしたい
デバイスを追加しフォーマット
fstabにマウントとディレクトリの紐づけを追記（新ディスクと/var）
マウントやリブート前に既存ファイルの移動対処
tmpDirを作成
mount (type) (device) (mountDir:tmpDir)
cp -a 旧 tmpDir
リブート
Posted by funa : 03:20 AM
| Web
| Comment (0)
| Trackback (0)
April 23, 2022
Goo ana 4
Posted by funa : 11:00 AM
| Web
| Comment (0)
| Trackback (0)
April 17, 2022
I drive or test driven
Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming.
TDD is dead. Long live testing. (DHH)I need to hire new techniques to help me solve many of my problems during programming: The pain will fade. Farewell TDD, old friend.
RIP TDD from Kent Beckそもそもテスト駆動開発の最後のところに、自分で考えてやれって書いてんなぁ、やらんでもええしって。そらそーやろ、自分で考えさせろや、やらんと分からんやろやらせろや、終了ーーーー
＝＝＝＝＝＝＝＝＝＝＝＝＝＝
となりそうだがドリドリについて
Assertするだけ？、何か一部しかテストでけへんの？
テストをコード化するのはいい
テストファーストとテストドリブンとユニットテストは違うらしいで
javascriptとかテストできんの？
ビジネスをソフトウェアでするだけ
ソフトウェアを捏ねくりまわしたいのではない
特にコードをビジネス通りに書くといい
プログラマー的変換するとよくない、ビジネスはビジネスとしてコード
ビジネスはコード上で完結せず現実があるから、オブジェクト化とかクラスは要らんと思う
データ等も人間が認識できる表形式のRDBでいい
ゲームとかコード上で完結するアプリや処理等はスペシャルなコードを書けばいい
現実がないのでオブジェクト化で発展できるかと
-実現したいことを箇条書きにする
-プログラムで処理できる内容にまで分解だけする
-コードにする
※実現したいことをそのままコードにする
脳に収まっとんのか？と。大事なのはこっちだろ。
-コミュニケーション
-組織力
-リサーチ
-実行
※企画/予算/収支、UX/デザインの決定
他人が使うソフトウェアなら必要、自分も使うソフトウェアなら不要では
自分でも使うくらい有用なものであるか
品質をどこで担保するか、機能だけなのかUXなのか
スーパープログラマには本質の部分にもっと時間を使って欲しい、死ぬ方が早い
あんまり機能をリファクターする機会がないかも
＋＋＋＋＋＋＋＋＋＋
ソフトウェア開発
Posted by funa : 09:54 AM
| Web
| Comment (0)
| Trackback (0)
April 1, 2022
GCP Python script
Googleがサポートするのは3つ
pip install google-cloud-dialogflow
GCPは下記のRESTがベースにあるらしいがコレが楽かと
2)REST https://googleapis.github.io/HowToREST
URLにAuthベアラーと必要ならJSONを投げてJSONを受け取る
URLに法則性があり get とか list
なぜかうまく行かないことが多い
3)ｇRPC https://grpc.io/
■サンプルコードのライブラリを検索するとAPIドキュメントは引っかかる
APIドキュメント
↓
APIはgithubにコード公開されている
親分はGoogle APIs on guthub
■python gcp Cloud API client libraryは下記のような所からサンプル、仕様を取る
client(bq)
pip install google-cloud-resource-manager
pip install google-cloud-biguery-datatransfer
#Pyton Bigquery
requirements.txt
google-cloud-bigquery==3.3.2
google-cloud-logging==3.2.2
----
from google.cloud import bigquery
import google.cloud.logging
import logging
bq = bigquery.Client()
sql = "select * from `unco`"
results = bq.query(sql)
row_counts = 0
for row in results:
bq_insert = bigquery.Client()
sql_insert = "insert into `benki` (a) values ('" + str(row.size) + "')"
logging.warning('### unco.size ' + str(row.size) + ' ###')
row_count += 1
#Python pubsubデータ取得(pubsub pushの場合)
requirements.txt
google-cloud-logging==3.2.2
----
import base64
import json
import google.cloud.logging
import logging
pubsub_data = base64.b64decode(event["data"]).decode("utf-8")
logging.warning('### pubsub data ' + str(pubsub_data) + ' ###')
json_pubsub_data = json.loads(pubsub_data)
#Python slack送信
requirements.txt
google-cloud-secret-manager==2.12.6
----
import requests
from google.cloud import secretmanager
import json
def slack_post(message):
client = secretmanager.SecretManagerServiceClient()
resource = "projects/12345678901/secrets/secretkey_xxx/versions/latest"
res = client.access_secret_version(name=resource)
slack_url = res.payload.data.decode("utf-8")
payload = {
"text": message,
}
notify = requests.post(slack_url,data=json.dumps(payload))
if notify.status_code != requests.codes.ok:
print("error")
else:
print("posted at slack url")
slack_post('続きは<http://yahoo.com| こちら>をクリックしてください)
@ .dockerignore
Dockerfile
README.md
*.pyc
*.pyo
*.pyd
__Pycache__
.pytest_cache
@ Dockerfile
FROM python:3.10-slim
ENV PYTHONUNBUFFERED True
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./
RUN pip install --no-cache-dir -r requirements.txt
RUN pip install Flask gunicorn
CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app
@ Dockerfile
FROM python:3.10-slim
WORKDIR /app
COPY app /app
RUN pip install -r requirements.txt --proxy=http://proxy:3128
CMD["python", "main.py"]
■Slack通知
incoming webhookかSlack apiの最低2種類がある
Slack apiではts(timestamp)が取得できスレッド返信ができるが、incomingは投稿だけ。incomingは管理画面でURLを取得しそこへPostすることで投稿ができる(URLのみで漏洩すると誰でも投稿できる、どのSlackアプリが投稿しているか分かるのでURLローテすれば良いが)。
apiはSlack固定のエンドポイントがありトークンをベアラに入れチャネル名を指定して投稿ができる。管理画面でトークン取得と権限スコープの設定をし、チャネル側でapiアプリの受け入れをintegrations設定する
URLあるいはトークンをGCPシクレMGRに入れて、アプリで読みEPへhttp通信する
APIのテスト送信ができる
■Oauth関連
ローカルの場合（VirtualBoxとか）
1) gcloudでログインをしてPython実行する
OauthクライアントIDの場合
2) ローカルPythonを実行するとAuthを聞いてくる>ブラウザが立ち上がる>ユーザ認証に変わる
3) WebアプリだとJSでAuthを聞く> 認証するとOauthクライアントIDでなくユーザ認証に変わる
設定方法
OauthクライアントIDをOauth同意画面>クレデンシャルで作成
デスクトップアプリは上記②、Webアプリは上記の③でID作成する
OauthクライアントIDをファイルかsecret mgrに入れてOauth認証通信をさせる
②flow = InstalledAppFlow.from_client_secrets_file(credentials, SCOPES)
③flow = InstalledAppFlow.from_client_config(json.loads(credentials), SCOPES)
サービスアカウントの場合
4) Cloud run等のサーバがOauth通信で認証し外部サービスを使う
設定方法
SAキーをファイルかsecret mgrに入れてプログラムからOauthで認証させ外部サービスを使う
EPはホスト名+パスだが、target_audienceはホスト名
GCPのOauthについて
https://www.marketechlabo.com/python-google-auth/
Docs API
https://developers.google.com/docs/api/how-tos/documents?hl=ja#python
https://rimever.hatenablog.com/entry/2019/10/16/060000
スコープ
https://developers.google.com/identity/protocols/oauth2/scopes?hl=ja#docs
google-api-python-client OAuth 2.0
https://googleapis.github.io/google-api-python-client/docs/oauth.html
Oauthライブラリ
https://google-auth.readthedocs.io/en/stable/reference/google.oauth2.credentials.html
https://google-auth-oauthlib.readthedocs.io/en/latest/reference/google_auth_oauthlib.flow.html
https://googleapis.dev/python/google-auth-oauthlib/latest/reference/google_auth_oauthlib.helpers.html
https://google-auth-oauthlib.readthedocs.io/en/latest/_modules/google_auth_oauthlib/flow.html#Flow.from_client_config
Oathライブラリのソースコード
https://github.com/googleapis/google-auth-library-python-oauthlib/blob/main/google_auth_oauthlib/helpers.py
OauthクライアントIDの仕様
https://github.com/googleapis/google-api-python-client/blob/main/docs/client-secrets.md
サービスアカウントで外部サービスのAPIを使う
https://www.coppla-note.net/posts/tutorial/google-calendar-api/
SAのサービス間認証の仕様
https://cloud.google.com/run/docs/authenticating/service-to-service?hl=ja#use_the_authentication_libraries
WebアプリのOauth認証
https://github.com/googleworkspace/python-samples/blob/main/drive/driveapp/main.py
https://stackoverflow.com/questions/10271110/python-oauth2-login-with-google
■Oauthについて
下記の少なくとも下記の種類があり、クライアントライブラリやコード等々で違いで使い分ける必要がある。今回はSA+シクレmgrを使用した。
-ローカル(gcloud auth login と認証)
-OauthクライアントID (アプリ上で認証が個人ユーザに引き継がれる)
-デスクトップ
-Webアプリ(jsでサイト上)
-サービスアカウント
-キーファイル
-シクレmgr
使用ライブラリーに注意
1) OauthクライアントID (ローカルファイル)
from google_auth_oauthlib flow import InstalledAppFlow
flow = InstalledAppFlow.from_client_secrets_file("credentials.json", SCOPES)
creds flow.run_local_server(port=0)
2) ローカルにおいたSAキー
from google auth import load_credentials_from_file
creds = load_credentials_from_file('credentials.json', SCOPES)[0]
3) Secret mgrにおいたSAキー
import json
from google.oauth2.service_account import Credentials
from google.cloud import secretmanager
client = secretmanager.SecretManagerServiceClient()
resource_name = "projects/()/secrets/{}/versions/latest" format(project_num, secret_name)
res = client.access_secret_version(name=resource_name)
credentials = res.payload.data.decode("utf-8")
cred_dict=json.loads(credentials)
creds = Credentials.from_service_account_info(cred_dict, scopes=SCOPES)
creds.refresh(Request())
※) これは使わない
from google.oauth2.service_account import IDTokenCredentials
#ファイルから
credentials = IDTokenCredentials.from_service_account_file(service_account,target_audience=target_audience)
#シクレmgrから
credentials = IDTokenCredentials.from_service_account_info(service_account.target_audience=target_audience)
ライブラリーのソースコード本体や仕様書
https://github.com/googleapis/google-auth-library-python-oauthlib/blob/main/google_auth_oauthlib/helpers.py
https://googleapis.dev/python/google-auth-oauthlib/latest/reference/google_auth_oauthlib.helpers.html
https://google-auth-oauthlib.readthedocs.io/en/latest/reference/google_auth_oauthlib.flow.html
https://google-auth-oauthlib.readthedocs.io/en/latest/_modules/google_auth_oauthlib/flow.html#Flow.from_client_config
サービスアカウントのライブラリ情報
https://google-auth.readthedocs.io/en/master/reference/google.auth.html
https://google-auth.readthedocs.io/en/master/reference/google.oauth2.service_account.html#module-google.oauth2.service_account
https://qiita.com/que9/items/38ff57831ea0e435b517
Posted by funa : 12:00 AM
| Web
| Comment (0)
| Trackback (0)
March 30, 2022
GCP runs off functions pubsub on scheduler
httpリクエストでコンテナを呼び出す
ローカルやterminalなどで作成しcmdでレジストリに入れるが、~/unco で下記作成
Dockerfile
.dockerignore
main.py
コンテナイメージにパッケージ化しContainer Registry にアップロード
gcloud auth application-default login
gcloud run deploy (対話型でデプロイまでできるが、SAはデフォルトになる）
gcloud builds submit --tag gcr.io/bangboo-run/unco (ビルドのみ、手動でコンソールでSAを指定しデプロイする)
gcloud builds submit --pack image=gcr.io/bangboo-run/unco ならDockerfile不要らしい
コンソールでデプロイ（trigger/permission）-新ver更新のときTagを付けなおす？
設定allow all traficとAllow unauthenticated invocations、権限allUsersにCloud Run Invokerではブラウザでも上手行く
設定allow all traficとrequire auth(IAM)、権限allAuthenticatedUsersにCloud Run Invokerのとき
IAMが要るのでターミナルから
curl https://unco-zp2aehj5rq-an.a.run.app/ ではIAM要求の場合は駄目
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://unco-zp2aehj5rq-an.a.run.app/ で上手行く
設定allow internal traffic onlyとrequire auth(IAM)、権限allAuthenticatedUsersにCloud Run Invokerのとき
ターミナルはinternal trafficでないから
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://unco-zp2aehj5rq-an.a.run.app/ でも駄目
インターナルでIAMを使うにはどうする？(同セグメントvpcからcurl bearer、vpc scかpubsubかEventarcだけ、terminalやschdulerは駄目）
→IAMを使うならallow all traficでいいのでは、allusersにinvokerを付与しなければいいし
→怖ければ同セグメントにVMを立ててそこからキック、あるいはScheduler手動 > Pubsub > Eventarc > Cloud runがいい
runのデフォルトのSAは別のrunでも同じSA実行として使い回されるので、別途作成したものを指定したい
デプロイをコンソールで実行するとサービスアカウントを指定できる（runのPermissonでそのSAにinvokerを付ける）
ブラウザ+IAMをrunで使うにはIAP
global ip、ドメイン、DNS、証明書、設定allow all traficとrequire auth(IAM)、権限各メールidにinvoker
LBはバックエンドにserverless network end groupを選べばいい
/// IAP
（古い方法）
IAPを使う場合はトリガーをAllow unauthenticated invocationsにする
現行だけだそうだが、IAPに全委任するために必要となっている
つまりIAPはLBが必要なため、Allow internal taraffic and from cloud load balancingとのコンビでトリガー設定をする
権限はCloud runのallusersが付き個別のinvokerは不要となり、必要なものはIAP上で付与をする
IAP上のWeb app userに Allautheticatedusersを入れると、識別できる誰でも入れてしまう
アクセスを許可したいユーザのみ個別でweb app userをIAPで付与すること
IAP で保護されたリソースへのアクセスの管理 | Identity-Aware Proxy | Google Cloud↓
（新しい方法）
特定のユーザだけCloudRunを利用させてたいなら：
(run)認証ユーザ＋(run)内部トラフィックとLB経由＋IAPのwebuserの設定
Cloud runでIAPを使用するIAP用隠れSAの権限：
プリンシパル: service-[PROJECT-NUMBER]@gcp-sa-iap.iam.gserviceaccount.com
ロール: Cloud Run invoker
AllUsersでなく、上記のIAP用隠れSAに権限を振ればIAPがrunを起動する
利用ユーザはIAPでwebuserの権限を与える
===
FROM python:3.9-slim
ENV PYTHONUNBUFFERED True
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./
#RUN pip install --no-cache-dir -r requirements.txt
RUN pip install Flask gunicorn
CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app
python requirements.txtでは google-cloud-bigqueryはインスコできるがsdkは無理
main.pyに from google.cloud import bigquery
Dockerfileでイメージでgoogle-cloud-sdkが入ればPythonのsubprocessでgcloud cmdが打てる
Dockerのベースイメージを FROM google/cloud-sdk:latest にして
RUN apt-get update && apt-get install -y \
python3-pip
RUN pip install --no-chache-dir -r requirements.txt
Cloud API client library for pythonを使うにはrequirements.txtに
google-api-python-client
Dockerfileの動作はCloud buildのhistoryで見れる
RUN which gcloud
RUN echo $PATH
RUN who
Cloud runのpython動作はloggingで見る
OSの実行ユーザとコンテナ内のユーザを合わせないとファイル読み込み等ができない
permission deniedになる
Cloud runのそれぞれのユーザが誰なのか分からない（上記でわかるが）
Dockerfileに RUN chmod -R 777 /app と入れてしまう
===
設定したrunのサービスのトリガー項目に
google.cloud.scheduler.v1.CloudScheduler.Run.Jobを設定（スケジューラ手動実行ならこれでも連携する）
google.cloud.pubsub.topic.v1.messagePublishedを設定 (Pubsub経由のEventArcなら）
色んなAPI有効が必要
クイックスタート: Pub/Sub メッセージを使用してイベントを受信する（Google Cloud CLI） | EventarcSchedulerとの連携に使う場合、手動実行でAudit logに記載され動くが、cron定期実行ならAudit logがなく動作しない事が分かった
internal trafficなら Scheduler > Pubsub > Eventarc > Cloud run
■Scheduler
get で https://run-service-name-.kuso.run.app
0 7 * * 1 毎週月曜の6時
Auth headerに add OIDC token
runのサービスにinvokerを付けたSAを指定
5回リトライ/最大リトライ0sで制限なし/バックオフ最小180s最大1h/期間倍5回
サービスアカウントにCloud service agentロールが必要
===
■Run jobs
runはジョブならFlask不要で簡易。だがEventarc-Schedule連携がまだGAでなくできないので単発手動実行用。
Procfile作成
web: python3 main.py
google-cloud-bigquery==3.3.2
main.py作成
コードを書く from google.cloud import bigquery
gcloud auth application-default login
run job実行とコンテナのプロジェクトを合わすなら
gcloud config set project bangboo-runs
下記は通常不要なようだ
gcloud auth configure-docker
Buildpackを使用してコンテナをビルド
Cloud buildデフォルトサービスアカウントにGCSバケット権限必要 123456@cloudbuild.gserviceaccount.com
gcloud builds submit --pack image=gcr.io/bangboo-runs/run_data_to_bq
bangboo-runsのコンテナレジストリにrun_data_to_bqができている
Cloud runでジョブを作成
gcloud beta run jobs create job-run-data-to-bq \
--image gcr.io/bangboo-runs/run_data_to_bq \
--task 1 \
--set-env-vars SLEEP_MS=10000 \
--set-env-vars FAIL_RATE=0.5 \
--max-retries 0 \
--region asia-northeast1
（gcloud beta run jobs create --helpで見るとenv-varのハンドルは何もないのでコードでエラースローする必要がありそう、そこでスリープとか使ってエラーを吐くと、リトライはしてくれそう。taskを複数にすると同時に何個も動く）
ローカルでテスト
docker run --rm -e FAIL_RATE=0.9 -e SLEEP_MS=1000 gcr.io/bangboo-runs/run_data_to_bq
Cloud runでジョブを実行
gcloud beta run jobs execute job-run-data-to-bq
============
from flask import Flask #モジュール読み込み
app = Flask(__name__) #Webアプリ作成
@app.route("/", methods=["GET","POST"]) #エンドポイント設定(ルーティング)
def index():
if __name__ == '__main__': #Webアプリ起動
app.run(debug=True)
request.form.get('name', None) 第2引数にデフォルト値入れられるらしい
■Flask LBでパスを分ける場合
LB
sub.domain.com /* backend-1
sub.domain.com /dir/* backend-2
Flask
@app.route("/dir/index", methods=["GET","POST"])
ドメインがこの場合：https://sub.domain.com/dir/index
Flaskには元のルートパスから指定する
●外部ファイルのstaticフォルダはカスタムルートが必要
Flaskルートの指定になるので/static/等になりLBで振り分けた場合は都合が悪い
Cloud runルートからの指定として/dir/static/style.css等にするにはカスタムルートが必要
Python flask
from flask import Flask, send_from_directory
@app.route('/dir/static/<path:filename>')
def custom_static(filename):
return send_from_directory('static', filename)
Python flask html
<link rel="stylesheet" href="{{ url_for('custom_static', filename='style.css') }}">
トップレベルにstaticフォルダを作り静的ファイルを入れる
ブラウザ表示
============
■functions
functionsもhttpで初めに実行される関数はFlaskのflask.Requestオブジェクトを受取る
PubsubトリガーとかEventarcトリガーもあるようだ
pubsubトリガーならinetrnal traffic onlyでOKだが、httpsはall traffic必要
requirementsは必要？標準ライブラリならimport文を本体に書いていれば良い
pprint.pprintでエラー、requirementsの場合PyPIで調べてバージョンも書こう
一時ファイルは/tmpというDIRであるがメモリーに保持される
テストでJSONを書く場合はキッチリ書く（文字はダブルクォート等）
{
"test" : "aaa"
}
functions invoker等のIAMはプロジェクトレベルではなく各functionsに対しての設定が必要そう
functionsのデプロイ時にinternal traffic や allow all trafic等の変更ができる
名前の変更や連携変更はfunctions再作成が必要で面倒
functions では gcloud cmdが打てない、SDKがないから
Functionsはデフォルトで環境変数を持っていてimport os > os.getenv()で取得できる
ENTRY_POINT 実行される関数、GCP_PROJECT 現在のGCPプロジェクトIDとか
topicという入れ物
メッセージがpublish投入される（コンソールでも作れるのでinternal trafficのトリガーにできる）
subscriptionでTopicのデータ取得状況を管理
subscriptionからsubscribeでメッセージの取得
メッセージは重複する仕様
Topicにメッセージを入れると勝手に紐づけられたアプリが動く
フィルターがあり条件を設定をできるがTopicを沢山作ればいいのでは
サブスクのpullはメールボックスみたいな入るだけ
functionsのpubsubで作った指定のTopicにメッセージが入れば動く
サブスクのpushも送信メールボックスみたいで送る
functionsのhttpで作ったエンドポイントに送られる
pullは謎に上手く行かなくなる？pushの方が安定かも
でもトラフィックの種類でpullならinternal traffic OK
pubsub pull -> functions：pull なら internal traficでもOK
pubsub push -> functions：push は http なので internal traficダメ
functionsのデプロイ時にinternal traffic や all等の変更もできる
例えばRunのTriggerでEventarcをPubsubで設定すれば指定のTopicに勝手にサブスクを作ってくれる
pubsubを使うときはrunとかfunctionsとかインスタンス1つの方がいい
べき等性の構成がなければバッチが勝手にリトライされ同時処理が起こる等で面倒
pubsubのリトライ無しで、returnで何とかhttp200レスポンスを返す
pythonだとmain()でエラーでもtry-exceptで投げてreturnを返すとhttp200になる
ackを返す時間デフォ10sであり処理が長いと駄目、-600sと長くするといい
pubsubはbase64ででコードするのにimport base64
pubsubはjsonでデータを持っていてimport json
Posted by funa : 07:59 PM
| Web
| Comment (0)
| Trackback (0)
February 26, 2022
GCP script
GitHub - GoogleCloudPlatform/professional-services: Common solutions and tools developed by Google Cloud's Professional Services team■gcloud cmd プロジェクト一覧
gcloud projects list --filter="bangboo OR fucu" --format=json
gcloud projects list --filter="bangboo OR fku" --format=json | grep -oP '(?<="name": ")[^"]*'
■pythonでgcloud cmd, 同期処理の方法（run）と非同期処理の方法（Popen）
Pythonからシェルコマンドを実行！subprocessでサブプロセスを実行する方法まとめ | DevelopersIO (classmethod.jp)--terminalでpython cmd.py python3.7どう？
import json
import subprocess
from subprocess import PIPE
p = subprocess.Popen(cmd , shell=True, stdout=subprocess.PIPE)
out, err = p.communicate()
out = json.loads(out)
[Python2.7] subprocess の使い方まとめ - Qiita python2.7やとちょい違うみたい、pipenvでバージョン管理したい？
--terminalでpython cmd.py
import subprocess
from subprocess import call
cmd = 'gcloud projects list --filter=bangboo --format=json'
subprocess.call(cmd, shell=True)
--runでcurl、cmd結果をPIPEで受けたいが
import os
import subprocess
from subprocess import call
from flask import Flask
app = Flask(__name__)
#メソッド省略でGETのみ
@app.route("/", methods=["GET","POST"])
def hello_world():
name = os.environ.get("NAME", "World")
cmd = 'gcloud projects list --filter=bangboo --format=json'
output = ' will die'
subprocess.call(cmd, shell=True)
name = "Hello {}!".format(name)
output = name + output
return output
if __name__ == "__main__":
app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
■pythonでbigquery
from google.cloud import bigquery
client = bigquery.Client()
QUERY = (
'SELECT name FROM `bigquery-public-data.usa_names.usa_1910_2013` '
'WHERE state = "TX" '
'LIMIT 100')
query_job = client.query(QUERY)
rows = query_job.result()
for row in rows:
print(row.name)
■BigQueryのトランザクション処理
///transactionの注意
複数のSQLをセミコロンで区切った上で連結しBEGIN～END;を一括で発行する必要がある（SQL１行毎発行ではダメ）
BEGINを複数、BEGIN内でTRANSACTIONを複数だとクエリの順番が入れ替わることがあるので注意
pythontry except else finally(tryはネストOK)とtime.sleepを入れ、挿入して服問い合わせを使い最新以外を削除する妥協策もある
最新1行だけでなく複数行OKで最新を取得するような構成にして
sql_begin = "BEGIN BEGIN TRANSACTION;"
sql_history = f"INSERT INTO `{ds.tbl}` (record_date. a, b) values (CURRENT_TIMESTAMP(), 'a', 'b');"
sql_commit = "COMMIT TRANSACTION;"
sql_end = "END;"
sql = sql_begin + sql_history + sql_commit + sql_end
■GCPのシークレットマネージャに重要な値を置き、それを取る
from google.cloud import secretmanager
client = secretmanager.SecretManagerServiceClient()
res = client.access_secret_version(resource_id)
value = res.payload.data.decode("utf-8")
GCPのSecret Managerで値を取得しようとしてハマった - Qiita■GCE（Docker使う版）へSSH後に何をするか
sudo apt-get update
Dockerインスコ
docker --version
who 誰がログインしているか
sudo gpasswd -a [ユーザ名] docker dockerグループへ追加？
■コードをコンテナ化
いったん /home/app_name に置いて
上手く行けば /usr/local/bin/app_name に移動すればいいのでは？
sudo nano 等でファイルを作る
Dockerfileの作成
RUN adduser -D myuser && chown -R myuser /myapp
（-Dはデフォルト設定で追加している、-Rは指定dir以下を再帰的に所有権変更）
USER myuser
（以降のRUNやENTRYPOINT等のINSTRUCTIONを実行するユーザを指定）
（USER nobody ならLINUXユーザで一般ユーザより弱い権限のもの）
Dockerfileをキック、あるいはdocker composeをキック
sudo docker build -t img_unco . でカレントのDockerfileをビルド
docker images リスト
docker tag [イメージID] img_unco:latest 名前がつかない場合
docker rmi [イメージID] 削除
docker ps -a コンテナ一覧
docker rm [コンテナID] 削除
ビルド後にdocker runが必要
docker container run -d --name cnt_unco -v ${pwd}:/app img_unco:latest
↓これが便利
docker container run -rm --name cnt_unco -v ${pwd}:/app img_unco:latest
オプション
-v ${pwd}:/app はOSローカル環境とコンテナ内のディレクトリを同期
-p 80:8000 はポート
-d はバックグラウンド実行（デタッチ）
-rm はrun後にコンテナを自動削除（イメージは残る）
docker compose exec コンテナ名 bash でコンテナに入れる
docker container ls コンテナのステータス確認
GCEはデフォルトサービスアカウントで動作するがgcloudコマンドはgcloud auth loginが必要等々のサービスアカウントのOauth問題等がある（DockerfileのUSERやRUNでgcloud auth default login等で調整する？）
■GCEセットアップ（Docker使わない版）
curl https://sdk.cloud.google.com | bash
gcloud init
直にOSにSDKをインスコしてもdefault service accoutだとVMスコープの問題が出る
自身のID/SAで権限を付けGCEにログインしgcloud initし操作する
sudo apt update
sudo apt install python3-pip
sudo apt-get install python3
sudo apt install jq
pip3 install --upgrade pip バージョン問題がPythonであるがこれをすると改善する場合あり
pip3 install --upgrade google-api-python-client
pip3 install --upgrade google-cloud-logging
pip3 install google-cloud 要る？
pip3 install google.cloud.bigquery 要る？
pip3 install google.cloud.logging 要る？
pipでうまくいかない場合 python3 -m pip install google.clud.bigquery と必要ならPythonを通して入れるべき所に入れる
Pythonコードで from google.cloud import logging 等を記載
import logging も必要（python標準のロギングでlogging.warning()でGCP loggingに書くため）
pipはpythonモジュール用、サブプロセスのOSでコマンドを打つならaptでインスコ
ちなみにrequirements.txtはpip、pip install -r requirements.txt
なお現設定を書き出すには pip freeze > requirements.txt
pip3 install jq をしていたが不要で sudo apt install jq でやり直した
pip3 list
pip3 uninstall jq
gcloud auth application-default login --scopes="https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/bigquery","https://www.googleapis.com/auth/drive"
コマンド打つならgcloud auth loginでログインする（Oauthスコープエラーになるのでスコープも付ける）
python3 main.py で実行
■Google Cloud における認証・認可
Posted by funa : 02:52 AM
| Web
| Comment (0)
| Trackback (0)
January 17, 2022
Panty gore-tex / Never stop fucking
防水、防風、透湿の機能。擦りとかには弱そうでバイクには勿体ないか
圧力が掛かると水が浸み込むので意味ないかと思い込んでいたが、北風の寒さを打消し、ムレがないので汗をかきにくく寒い日の活動にメチャいい
infiniumは軽くて柔らかいが防水性がない
proはgore-texよりも透湿性が約30％アップ
普通30とか70デニールとかだがマンジャケは150デニール、糸の太さらしいが密度も上がる？マンジャケは裏生地もありトータル厚いがgore-texだけの厚さの違いは全然分からん
150DやProの方や、シャカシャカしている方が強いと思われるが、強度は張付ける生地側によるところが大きいのか触らなよく分からん→触って好みを買うしか
日本やアジアンサイズでMの場合は、並行輸入は要注意でワンサイズでかいのでS
futurelightは柔らかい、多分軽くて透湿性が優れてそうだが、シャカシャカのgore-texのパンティのゴワツキが好み、27年目の鎮魂
ITやinternetを上手く使えば戦争なんか起こるはずがない、そうならなかった あぱー
Posted by funa : 02:23 AM
| Gadget
| Comment (0)
| Trackback (0)
waspはもう米国を支配していない
