■21/5/2 10:14PM
Terrafirma
公式https://www.terraform.io/docs/index.html
導入https://www.terraform.io/guides/core-workflow.html推奨方法https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part1.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part2.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.1.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.2.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.3.html https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.4.html
チュートリアルhttps://learn.hashicorp.com/collections/terraform/gcp-get-startedHCLhttps://www.terraform.io/docs/language/index.htmlCLI aka cmd（アルファベットリストから使う）https://www.terraform.io/docs/cli/auth/index.htmlGCP用リファレンスhttps://registry.terraform.io/providers/hashicorp/google/latest/docs
お便強https://qiita.com/minamijoyo/items/1f57c62bed781ab8f4d7https://qiita.com/donko_/items/6289bb31fecfce2cda79https://www.apps-gcp.com/infra-automation-01/TerraformでGCP環境を構築してみる | GMOアドパートナーズグループ TECH BLOG byGMO (gmo-ap.jp)https://colsis.jp/blog/gcpterraform/
Infra as codeとしてインフラの構築や設定をコード化できる特にクラウドだと構築の自動化や構成管理等でのレバレッジが強力
■段階
Terraformとは?基本知識とTerraformのメリット4つを紹介 | テックマガジン from FEnetインフラ
必要なリソースをTerraform化>workspaceの活用>main.tfの共通部分をmodule化
Terraform運用事例書きました - pixiv insidemoduleは構成に合わないようなリファクタリングが必要になった時にterraform state mv が必要になってとたんにつらい、moduleを細分化しすぎるとvariable と output が大量に必要になって書きづらい、moduleは再利用できる複数のリソースの単位（プログラミング言語でいうところの関数みたいなもの）で作るのがしっくり
Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる - Qiitaリソースの差分を無視するlifecycleブロックを使うresource "aws_autoscaling_group" "app_1" { name = "app-asg-1" lifecycle { ignore_changes = ["load_balancers"] create_before_destroy = true//新しいのを作ってから古いのを削除 }}外部ファイルを文字列として読み込むresource "aws_iam_role" "ec2_role" { name = "ec2-role" assume_role_policy = "${file("./ec2_assume_role_policy.json")}"}1つのディレクトリで複数のStateを扱うWorkspaceという機能もあるのですが、個人的には普通にディレクトリを分けて管理する方が楽production/stagingが完全に同じリソース構成で、設定のパラメータの差分がちょっとだけあるという理想的な世界ではWorkspaceでも運用できるかもしれませんが、現実的にはstagingだけリリース前の検証用の一時的なリソースが立ってたりとか、完全に同じ構成にならないことも多いので、モジュールの読み込みの有無や一部の環境だけ存在するリソースなどの差分を吸収できる場所があったほうが都合がよい
Terraform職人再入門2020 - Qiita
モジュールが公式から提供されている
Browse Modules | Terraform Registry
Terraform の terraform.tfvars とは | 30歳未経験からのITエンジニア (se-from30.com)
環境情報は外部ファイルが基本prd/stg/dev環境はprd.tfvars, stg.tfvars, dev.tfvarsを用意.tfvars 各環境の設定 aws_access_key = "XXXXXXXXXXXXXXXXXXXX" aws_secret_key = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" aws_region = "eu-west-1"main.tf terraform { required_version = "= 0.12.26" } provider "aws" { version = "2.66.0" access_key = var.aws_access_key secret_key = var.aws_secret_key region = var.aws_region }var.tf 空の受け皿 variable aws_access_key {} variable aws_secret_key {} variable aws_region {}
Terraform で変数を使う - Qiita
実行時に-var-fileで値ファイルを指定して環境などを切り替えると良いかもしれない terrafrom plan -var-file=dev.tfvars terrafrom plan -var-file=prod.tfvars
変数ファイル指定がないときは変数でdefaultに入れておく、descriptionで変数の説明もかける variable "foo" { type = "string" default = "default-var" description = "Sample Variable" }変数ファイルを異なるバックエンド(フォルダ構成)で共有したいときはシンボリックリンクを貼る ln -s ../common/shared_var.tf shared_var.tf
TerraformでGCPのリソースの作成と変数から値を読み込む - y-zumiの日記 (hatenablog.com)credentials等の秘匿したい変数を外部のファイルやコマンドライン引数から読み込むvariable "credentials_file" {} ＠var.tf 変数を定義し空にしておくcredentials = file(var.credentials_file) ＠main.tf ファイルを読むがファイル名は変数terraform plan -var 'project=' -var 'credentials_file=.json' ＠cmd プロジェクトとクレデンをコマンド時に指定
他にもvars.tfvars設定ファイル(行頭variableが不要)、TF_VAR_環境変数による指定
Input Variables - Configuration Language - Terraform by HashiCorp-var-fileで変数ファイルを明示してcmd、ファイル名は.tfvars/.tfvars.json-varで変数を明示してcmd順序があり後の読込でオーバーライド
Terraformのベストなプラクティスってなんだろうか | フューチャー技術ブログ (future-architect.github.io)
Workspace派、module派、ディレクトリ分離派
↓
HCLの変数は基本2種類のlocalとvariablevariableはグローバル変数、ファイル外やコマンドラインから使える
その他の変数参照方法としては（上から優先に適応） コマンド引数 一時的に使用 変数ファイル terraform.tfvars git管理等で外部ファイルで？ 環境変数 TF_VAR_ 実行ログに残らない鍵情報等workspaceは使わない、moduleを限定的に使う
設定をコード化>Gitレポジトリに置く>設定内容、作業履歴の明確化、チームでの運用性向上
■特性TFの影響を反映するのはterraform applyの時だけ、tfファイルとtfstateの差分を実際にリソース作成する
tfファイルで変更した場合、TFはリソースの再作成を行うので一度消えることになる（大体は単位が権限だったりで影響がないだけでplanで要注意）
terraform planはtfとtfstateと実体の差なので、実体があってもtfstateになければwill be createdでplan時は表示されるterraform importはtfファイルからtfstateへ記載だけを行う(実体からも情報を取得しtfstateに入れる) カレントdirの全.tfファイルor.tf.jsonを評価するのでtfファイルの名は何でもいい
各リソースに対してTF化するかは選択ができるが、TFする場合はそのリソースに必要な全記載をTFファイルに行うterraform import tfResourceID.yourResourceName gcpIdentifier のコマンド terrafrom import google_bigquery_dataset.tf-1 bangboo-prj/test-dataset tfResourceID(リソースIDというようタイプ：リソース種別)はTF指定のもの、yourResourceName (リソース名)は任意のもの 構成ファイル.tfはローカルのものが使われる、importするとtfstateに反映 GCP identifierはTF公式サイトの各サービスの一番下import項目を見ると指定内容が分かるのでGCPを見て拾ってくる terraform state list TF化されているリソースを見る terrarorm apply時にもtfstateは更新される（オプション-refresh=falseで無効可） またapply時に-target=xxxでデプロイするリソースを特定できる(TFファイルだけでなくTFステートもターゲットになる)
Syntax - Configuration Language - Terraform by HashiCorp コメントは#が基本、//や/**/も使える
Terraform v0.12で変わるHCLの記述について - Qiita localsや変数、リストやマップ等
Terraform職人再入門2020 - Qiita yamldecodeやjsonencode等
Terraformの基本 - Foreverly (hatenablog.com)
変数 variable(input var)はcmd実行時に変数を上書きできるが、localsはできない outputはapply時にterminalで値が確認できる、moduleから値を取得する
google_bigquery_connection | Resources | hashicorp/google | Terraform Registry
ドット繋ぎで値を扱えるresource "google_sql_database_instance" "instance" { provider = google-beta name = "my-database-instance"}resource "google_sql_database" "db" { instance = google_sql_database_instance.instance.name name = "db"}
ToSetは値設定をするが順不同で重複を省く
resource "xxx" "aaa" { for_each = toset(["foo", "bar", "bar"]) でbar, foo name = each.key}
for_each/eachのループ
locals {
sg = { foo = "FOO"
bar = "BAR"
}}
resource "xxx" "aaa" {
for_each = local.sg
name = each.key
description = each.value
}
mapをリストしたものをfor_eachTerraformのfor_eachにmapのlistを渡してループしたい - Qiitalocals { images = [ { name = "foo", image = "alpine" }, { name = "bar", image = "debian" }, ]}resource "docker_container" "this" { for_each = { for i in local.images : i.name => i } # こう書くのが正しい name = each.value.name image = each.value.image}
terraform importはリソース単位、更新はできず削除してから追加 terraform state rm google_bigquery_dataset.tf-1
実設定とimportの内容が違う場合は実設定の情報でtfstate化されるようだ(importは項目を入れ込む感じ？)
なので実環境に変更を加えるにはterrafrom apply、tfstate化もされtfファイル/tfstate/実設定の3者で同じになる
apply時にtfstateと実設定が違う場合、例えば既存設定がある場合は重複エラーになりapplyできず、importしtfstateと実設定を同じにしてから、tfファイルの内容をapplyすることが必要
terraform importで対象プロジェクトを間違えるとハマる
通常のterraform applyではproviderの情報を使用してプロジェクトを決めるが、importはハードコードするのでimportを間違えばなぜ変な変更がでるのかわからなくなる（プロジェクトが変なものはstateを調べ、terraform state rmするしか）
for_eachで書いた.tfをterraform importする | DevelopersIO (classmethod.jp)
ユーザ指定は user:aaa@xxx.com だったりメールグループなら group:aaa@xxx.com
■セットアップ 作業ディレクトリの作成(プロジェクトに対するローカルのフォルダ） プロバイダを指定したtfファイルの作成(gcsにstateを置く設定が良い
provider "google" { project = "bangboo-kuso" } terraform { backend "gcs" { bucket = "bangboo-kuso-terraform" } } terraform init ローカルに対して初期化
プロジェクトレベルownerのサービスアカウントを持っておく セットアップする際にtfsateのbackend保存場所のbucket部分をコメントアウト bucketを作るterraformを実施しbucketを作成しつつlocalにtfstateファイルを作成 再度terraformをするとtfstateファイルがbucketにコピーされる bucket部分のコメントアウトを外すと次回tfからはバケットにtfstate更新する
このときローカルtfstateの内容をバケットに写すか聞かれるが写す
（写さないと差分しかバケットに行かないのでimport等が必要になる）
■既存リソースのTF化のおおよその作業 リソースタイプと名前を定義したtfファイルを作成する(任意のリソース名、基本ユニーク、纏められるものは重複してもいい)
resource "google_cloudfunctions_function" "fuckin" { ... をtfファイルに記載
tfResourceID(リソースIDというようタイプ：リソース種別)とyourResourceName (リソース名) だけで リソースタイプや個別パラメータは公式ドキュメントを参照しながら定義 https://registry.terraform.io/providers/hashicorp/google/latest/docs
(簡単)tfファイル内で１行目以外は空で、terraform planをするとエラーで必要なものが分かるので、それを埋める
planが通ると自動的に値をサーバから拾ってくる（importすればtfstate.tfに入っている or コピーしてTFに入れる）
planでダメならterraform state show tfResourceID.yourResourceName でstateを見てtfファイルにパラメータを定義していく
暫定に空でリソースをTFファイルに記載しterraform import、次にtfstateを調査する
terraform state list tfstateファイルにあるアセットを一覧
terraform import google_bigquery_table.xxx project/dataset/table インポート
terraform state show google_bigquery_table.xxx tfstateの該当部を表示
terraform state rm google_bigquery_table.xxx インポート取り消し
TF定義は複数の方法がある、最終GCP公式のRestAPIで確認するしか terraform importする（公式ドキュメントの一番下にimportコマンドの指定がある） terraform planして差分がなくなるまでtfファイルを修正する import(tfstate)の修正は一度stateから削除する terraform state rm google_bigquery_dataset.tf-1 (既存リソースがあってもあくまでtfファイルとtfstateの差分なのでinitした状態でplanしてもup-to-dateと表示されるだけ)
tfstateファイルにおかしなものが無いか確認、keyとか含まれないか
■個別
リファレンスでoptionalとなっていてもtfファイルでは必要な場合もある tfstateファイルからは必要ないとして自動的に削除されるがスプシをBQでみれるFederatedQueryはテーブルだけ定義しimportしstate show調査 urlをTFファイルに記載するシャーディング（日付別）テーブルは定義できないのでは 生成するクエリの方をTF化したい
Authorized viewはモジュールがあるがconflictがあり全消えする場合がありTF化にまだ向かない
google_bigquery_dataset_iam_memberでもAuthorized viewをはがしてしまう。Authorized viewを使っている個所は google_bigquery_dataset_access あるいは google_bigquery_dataset の access フィールドを使う。google_bigquer_dataset_iam_policy と google_bigquery_iam_binding は Authoritative で権限追加でなく権限強制設定でコンソール付与分を引き剝がすので、使わない方が安全。なお、Authorized view と Routines はTerraform化できない事が分かっている（2022/4時点）ScheduledQuery は Terraform化できるが実行者の設定ができない（Terraform実行者がSQ実行者？誰？）
BQ関連ではデータセット定義、テーブル定義、ビュー定義、フェデレテッドクエリ定義、ScheduledQuery定義をTerraformで行いBQ権限定義、AuthorizedView定義、Routines定義は行わない
BQ権限を定義するならデータセットレベルはgoogle_bigquery_dataset_access
プロジェクトレベルはgoogle_project_iam_memberで実施すると別なので安全らしい？
■TF公式ドキュメント
google_organization_iam_custom_role | Resources | hashicorp/google | Terraform Registry
google_organization_iam | Resources | hashicorp/google | Terraform Registry
カスタムロールを設定して、組織レベルのIAMでそれを使いたい
TFのorg_iamページのArgument referenceのrole項目を見ると Note that custom roles must be of the format organizations/{{org_id}}/roles/{{role_id}} TFのorg_iam_custom_roleページのAttributes referenceのrole項目を見ると id - an identifier for the resource with the format organizations/{{org_id}}/roles/{{role_id}}
で下記と分かる、使用側と被使用側のTFマニュアルを両方確認するresource "google_organization_iam_custom_role" "my-custom-role" { role_id = "myCustomRole" org_id = "123456789" title = "My Custom Role" description = "A description" permissions = ["iam.roles.list", "iam.roles.create", "iam.roles.delete"]}resource "google_organization_iam_member" "my-organization" { org_id = "123456789" role = google_organization_iam_custom_role.my-custom-role.id
#あるいは通常"roles/bigquery.dataEditor"のようにいれるがorganizations/0123456789/roles/chinkoといれる member = "user:jane@example.com"}
↑
resourceの2番目リソース名を定義しますが任意の名前を指定します
ここが同じ項目はユニーク制限がない場合は追加としてまとめられます
通常はユニークにしterraformで管理するリソース名(yourResourceName)を宣言します
※1番目のリソースタイプ内でユニークにするのが基本（全体でもユニークの方が分かり易い）
TFファイルに定義をしたい →定義したいリソースのArgument referenceの項目を設定TFファイルに定義した内容を変数で使いたい →使いたいリソースのAttributes referenceを見る
terraform importしたい →インポしたいリソースのページ一番下のimportコマンドの指定を見る
■他に一般的なTF（既存がimportされると以下で変更をapplyして運用） terraform -v 稼働確認
terraform fmt ファイルの記述フォーマットを整える terraform validate ファイルの検証 terraform plan アクションを計画
terraform apply 最後に変更を適応 terraform show ステータスを確認、一覧 terraform destroy で簡単にインフラの吐き、initができないとき必要そう
■特定のリソースだけ適応したい terraform plan -target="tfResourceID.yourResourceName"
terraform apply -target="tfResourceID.yourResourceName"
TFファイルだけでなくTFステートもターゲットに含まれる
これでTFファイルにコードがなくTFステートだけにあるものを指定して削除等もできる
■TFのcount
数を指定してその個数のリソースを作る。なのだが enable_lien = true モジュール側/変数側でこう設定し count = var.enable_lien ? 1 : 0 リソース側で3項演算子を使えばIFのように使える
※for loopのようなインクリのcount"+="でなく"="の1発実行なので3項演算子でIFになる
■エラー
bigquery access denied：
gcloud auth login --enable-gdrive-accessgcloud auth application-default login --scopes="https://www.googleapis.com/auth/drive","https://www.googleapis.com/auth/cloud-platform"BigQueryでGoogleドライブデータへのクエリでエラーが出るときの対処 (zenn.dev)
排他処理でロックが残る：他の作業者がいなければ、terraform apply -lock=false で一時的に無視をして続行
エラーIDに対して terraform force-unlock id_num963103164Terraform で state のロックを解除する方法、ロックを手動で行う方法 | ゲンゾウ用ポストイット (genzouw.com)
TerraformでState Lockエラーが発生したら | DevelopersIO (classmethod.jp)
■terraformのバージョン管理.terraform.lock.hclファイルでGCP provider等のライブラリのバージョン管理をしている、pyenvのPipfile.lockみたいなHash差分が記載されている、terraform init等で生成されapply時の設定が担保される、通常tfファイルでproviderのバージョンを記載すればよいので不要と思われる
.terraform-versionファイルでterraform自体の要求バージョンを担保できるtfenvの.terraform-versionファイルにはバージョンベタ書きしなくてもOK | DevelopersIO (classmethod.jp)通常はtfenvを使えばよい、tfファイルでrequired_versionを記載すればよいので不要と思われる
■tfenvを使う場合tfenv install 1.0.0
tfenv listtfenv use 1.0.0
terraform init terraform workspace list terraform workspace select ore_spacemain.tf作成し記載 terraform fmt tfファイルのフォーマット（書式は適当で書けばいい） gcloud auth login ローカル操作のための認証 gcloud auth application-default login SDKを実行のための認証 API&Servicesでクレデンシャルは取得できそう、key=xxxx既存のリソースを調査terrafrom import google_storage_bucket.pri-bucket project-abc123/asia-northeast1/pri-bucket でimportとか terraform refresh tfstateの最新化、どのタイミングで使う？
■既存のリソースを調査
Terraform と gcloud CLI を使用した完璧な Google Cloud インフラストラクチャの構築 | Google Cloud Blog
gcloud beta resource-config bulk-export --help
gcloud beta resource-config bulk-export --project=kuso12345 --resource-format=terraform --path=/path/to/dir/
対応を見ると数が少ないgcloud beta resource-config list-resource-types --format=json --project=kuso12345
terraformer import google list --projects=xxxx-123 で対象のリソース確認terraformer import google --resources=instances,forwardingRules --regions=us-west1 --projects=xxxx-123 とか
既存リソースimport
https://www.apps-gcp.com/terraformit-gcp/https://qiita.com/uu4k/items/48d3ecfefe57dba1d7e1
■Terraform applyで意図しない権限削除で障害が発生する
Terraform x GCP で、IAM権限を全削除してしまった - Qiita
resource "google_project_iam_policy" "unko" { project = "my-project" role = "roles/noguso" members = [ "serviceAccount:${google_service_account.baka.email}" ]}google_project_iam_policy：書き換えるので他は無くなる（他を消したいときに使う）google_project_iam_binding：付与、Authritativeだが他は現状維持？
google_project_iam_member：付与、Non-authoritativeで安全、まとめ難いか
※_iam_policyと_iam_bindingとt_iam_memberは一緒に使えない ※_iam_bindingと_iam_memberは一緒に使える
google_bigquery_dataset_iam_binding：（承認済みビューの権限はなくなる＞google_bigquery_dataset_accessを使え）google_bigquery_dataset_iam_member：roleとmemberを1対1でresourceを作りまくる、Non-authoritative
※_iam_policyや_bindingはまとめ易そうだが権限消しそう
google_bigquery_dataset_iam_memberでもAuthorized viewをはがしてしまう。Authorized viewを使っている個所は google_bigquery_dataset_access あるいは google_bigquery_dataset の access フィールドを使う。
Terraform で GCP のサービスアカウントを管理する - Eng (なりたい) (hatenablog.com)
Terraform で GCP IAM 設定どれ使うのがいいのか - pokutuna (scrapbox.io)
google_project_iam | Resources | hashicorp/google | Terraform Registry
Authoritative: TFに明示していないものをApply時に削除しますという意、TFの権威
Non-authoritative: TFは権威を示さず、TFに明示していないものは現状維持ですという意
■勝手に公開
terraform vpc auto_create_subnetworks = falseにせなサブネットを公開して作りよる
Cloud sqlのtfファイルに記述がなくてもtf stateにはPWが出てしまう＞tf化したくない
■Applyの依存関係はdepends_on(プロジェクト作成の前に権限を付与しようとしてエラー等の順序)
[Terraform]Module間の値の受け渡しについて | DevelopersIO (classmethod.jp)
これより先にあれをTFしてくれという記述
■データセット
google_bigquery_dataset | Resources | hashicorp/google | Terraform Registry
スキーマ取得: bq show --schema --format=prettyjson bangboo-prj:test-dataset.tbl001
ビューはコンソール＞BQ＞該当ビュー＞detailからコピー
■組織ポリシー
google_organization_policy | Resources | hashicorp/google | Terraform Registry
制約について | Resource Manager のドキュメント | Google Cloud
■parallelismで早くなるかもしれない
あなたのterraform planを手軽に高速化する（かもしれない）魔法の言葉 - Qiita
シェル変数を設定、確認cmdは printenvexport TF_CLI_ARGS_plan="--parallelism=50"export TF_CLI_ARGS_apply="$TF_CLI_ARGS_plan"
■テスト
TF Apply後には検証をしっかりしたい、最低Apply後にPlanを再実行したい、テストスクリプト的にチェックしたい
適応されていないことや、TF定義とtfstateと実設定の差分が想定と違うことがある感じがするからだ
moduleを含めて条件的な書き方だと、適応の順序の関係で適応が抜け2回以上TF applyしないといけなかったり
■TFファイルを分割し部分的に別環境へTFファイルを移行したい
tf stateファイルを新環境用にコピー
TFファイルを分割：現行の部分的に削除したTFファイル、と新環境用のTFファイルを準備
tf stateから不要部分を削除
terrafrom state rm {{asset}}
terrafrom planで差分がないことを確認
新環境用にコピーしたtf stateファイルを編集し準備
下の terraform state push xxx.tfstate で変更された状態をtf stateファイルに書き戻すことができる？
このコマンドを実行する前に必要に応じて terraform state pull で最新の状態を取得？ ダメなら terraform state rm で不要分を削る新環境用にtfファイルを準備
新環境で下記を実行
terraform init
terraform state push xxx.tfstate
terraform planで差分がないことを確認
■GCP権限（メールの変名時）
GCPはGWS gmailメールの変名に追従して権限も付与状態も変化がないしかしterraformは追従しないためtfファイルで使っている場合は変更する
■gcloud cmdhttps://www.devsamurai.com/ja/gcp-terraform-101/ gcloud projects list 権限あるプロジェクトを表示 gcloud config set project [prjID] ワーキングプロジェクトの設定 gcloud services enable iam.googleapis.com サービスの有効化 gcloud iam service-accounts create terraform-serviceaccount \ --display-name "Account for Terraform" サービスアカウント作成 gcloud projects add-iam-policy-binding [PROJECT_ID] --member serviceAccount:terraform-serviceaccount@[PROJECT_ID].iam.gserviceaccount.com --role roles/editor 権限付与 gcloud iam service-accounts keys create path_to_save/account.json --iam-account terraform-serviceaccount@[PROJECT_ID].iam.gserviceaccount.com クレデン発行 export GOOGLE_CLOUD_KEYFILE_JSON=path_to/account.json クレデン設定
↑サービスアカウントで認証 環境変数にファイルパスを渡す
gcloud auth application-default login だと個人
これにクレデンシャルファイルのパスを渡すとサービスアカウントでgcloudコマンド打てるはず
Terraformで複数リージョンをまたいだリソース制御する (mosuke.tech)
Terraform workspaceを利用して環境毎のリソース名の変更を行う (mosuke.tech)
End
Comment (0)
■21/4/2 1:00AM
Linux cmd2
■プロキシを入れないとアクセスできない、が同セグメントは不要なためno proxy設定するLinuxの場合 export http_proxy=http://proxy:3128 export https_proxy=http://proxy:3128 export no_proxy=localhost,127.0.0.1,.in-xxx.comコマンドプロンプト set http_proxy=http://proxy:3128 set https_proxy=http://proxy:3128 set no_proxy=localhost,127.0.0.1,in-xxx.comPowerShell $env:http_proxy="http://proxy:3128" $env:https_proxy="http://proxy:3128" $env:no_proxy="localhost,127.0.0.1,in-xxx.com"
■ncコマンドでプロキシ確認 自分の環境から環境用のproxy に接続できるかどうか? apt install netcat-openbsd nc-vz. proxy 3128 でプロキシ確認 nc-vz 127.0.0.1 20-100 自分自身に対してTCP20~100番ポートをスキャンし成功するとsucceed!! cnc-likすると簡易的に好きなポートでサーバーを起動できる 特定のボートの疎通確認などに nc-lk 8000 -l オプション:サーバーモードで指定したポートで接続を待ち受ける 特権ポート (0-1023)までは、名前の通り特権が無いと、コマンドが通らない -kオプション:接続が終了してもプロセスを終了せず継続し新しい接続を待ち受ける レスポンスのデータを見たいなら、python モジュール等で python3-mhttp.server 8080
■LDAP mgrとLDAP LDAP managerは製品名で個人ユーザと所属グループが管理される。
製品概要 | 国産統合ID管理パッケージソフト「LDAP Manager」 OpenLdapはLinuxでよくつかわれているディレクトリサービス (ID管理)
OpenLDAP で理解するディレクトリサービス入門 | ほげほげテクノロジー
■sudoers について どのユーザやグループがどのsudo コマンドを利用することができるのかの定義の記載があり、ユーザとグループの設定で権限を制御 どのユーザがどのsudo コマンドを利用することができるのか $sudo -l idコマンドで自分の所属サブグループを確認 $id
元のページ
/// BANGBOO BLOG /// - Linux cmd
Comment (0)
■21/4/2 12:00AM
Linux cmd
■Linux terminal
tabで入力補完
↑↓で入力履歴呼び出し
^qはCtrl+qを押すという意味
半角/全角キー 日本語を切り替える（画面右上にもIMEがある、win+spaceの場合も）
ls -la ディレクトリ内を表示
ls -a 隠しファイルを含み表示
（GUI）ctl+h 隠しファイルを表示（メニューでもチェックで可）
pwd 現ワーク中のディレクトリを表示
cd ../ 上に上がる
clear 表示内容を消す
mv beforeName.text afterName.txt ファイル名変更
rm -R ディレクトリ名 削除、ファイルはrm a.txt
ls -l > hoge.txt >結果を上書き
ls -l >> hoge.txt >>結果を追記
printenv 環境変数表示 printenv xで特定表示
grep aaa -rl ./ カレントディレクトリ以下からファイル内にaaaが含まれるファイルを検索
grep -R $keyword *.py .pyファイルからkeywordを検索
sudo - 一般ユーザが特権操作する sudo省略sudo -i rootに切り替える
sudo -iu <username> 特権ユーザ切り替え
テキスト選択
Shift↑or↓ で行全体
home(+fn)で行頭、end(+fn)で行末移動
nano text.txt 作成あるいは開く、nano簡単かも、画面下コマンドでctrl+?すればいい
コマンドM-UはEsc+u
ctrl+k で１行削除
$()ドル記号と括弧で囲んだコマンドは実行結果を出力し展開echo "現在のディレクトリは、$(basename $(pwd))です"
パッククォートは囲った中身をコマンドとして実行しその結果を出力echo "今日は、`date +%m月%d日`です。"
変数と$()とバッククォートを使ってワンライナー【shell/bash】変数代入で``や$()の使う場面を忘れた時に見る記法まとめ (zenn.dev)
■viエディタ
sudo apt install vim
vi text.txt ファイル作成あるいは開く
viは2つ＋αのモード ┣コマンドモード ┃┗コロンモード（exモード:祖先のラインエディタ） ┗入力モード
https://docs.oracle.com/cd/E19253-01/816-3946/editorvi-5/index.html
viのコロンモードコロンモードのコマンドは、このw、q、q!、x、$5... - Yahoo!知恵袋Escでコマンドへ抜ける
┗挿入 i （入力モード）
ファイル名を指定し保存 :w new_file_name.txt
強制保存のコマンド :w!
保存せず終了 :q 強制終了 :q!:10 10行目に移動:set number 行数を表示:num 現在のカーソル位置行数を表示
クリップボードをペースト iで挿入モードに入り Shift+Insertvi内でコピペ：yコマンドのコピー、pコマンドのペーストなので下記の様にする 2yw ならカーソルから2単語コピーされます 3yl ならカーソルから3文字コピーされます y$ ならカーソルから行末までコピーされます p ならカーソルの後ろにペーストされます$ カーソルを行末へG カーソルを最終行行頭へ- 前行の行頭へEnter 次行の行頭へw カーソルを1語進めるb カーソルを1語戻すCtrl-d 1/2画面下へ(down)Ctrl-u 1/2画面上へ(up)Ctrl-f 1画面下へ(foward)Ctrl-b 1画面上へ(back)/文字列(Enter要) 文字列検索(スラッシュ) ┣n 次の検索文字列へ ┗N 前の検索文字列へ 保存して終了 :wq 保存して強制終了 :wq!
コマンド集 viコマンド集 (ritsumei.ac.jp)カーソル移動 viでのカーソル移動方法を一通りまとめました (eng-entrance.com)検索 【初心者向け】viでの文字列の検索方法を一通り (eng-entrance.com)
■環境変数は下記の順で探す、なので必要なら下位のものを上にコピー
~/.bash_profile~/.bash_login~/.profile
source ~/.bash_profile 編集したbashrcをbash_profileに反映させる
bashrcはbash起動毎、bash_profileはログイン毎
■SSHの設定
Linuxコマンド【 ssh-keygen 】認証用の鍵を生成 - Linux入門 - Webkaru
$ ssh-keygen
パスフレーズは空でも設定上は問題ないが塩っ気が足らん気が秘密鍵（id_rsa）と公開鍵（id_rsa.pub）が生成され、ホームディレクトリに作成される /home/yourID/.ssh/id_rsa /home/yourID/.ssh/id_rsa.pub.公開鍵をSSHサーバや外部サービスに登録する等して使う、秘密鍵は明かさないこと
SSHクライアントのproxy越えの設定方法 (mydns.jp)
プロキシbinのインスコ
$ sudo apt-get install connect-proxy
ホームにsshキーができているので$ vi ~/.ssh/configHost oketsu HostName 1.XXX.XXX.XXX User hoge IdentityFile ~/.ssh/id_rsa.pub LocalForward 5912 localhost:5902 ProxyCommand connect-proxy -H proxy.syanai.in:8022 %h %p
Host github.com HostName ssh.github.com
Port 443
IdentityFile ~/.ssh/id_rsa.pub ProxyCommand connect-proxy -H proxy.syanai.in:3128 %h %p User githoge$ chmod 600 .ssh/config下記のように実行すると、ログイン/GITできます。$ ssh oketsu
$ git clone githoge@github.com:kusogitry.git$ id 所属グループ等を表示
$ uname -n;id;date
■NW設定
/etc/resolve.conf
nameserver 88.88.88.88~/.profile とか .bashrc とか export http_proxy=http://proxy/3128/etc/apt/apt.conf
ip addr
■スクリプト実行
nohup python3 main.py & ユーザディレクトリにnohup.outログが実行完了時に一度に保存される（重いと思われる）nohup python3 main.py > /dev/null 2>&1 & ログなし nohupはバックグラウンド実行、ログアウトしても実行続けるjobs ジョブリストを出すfg ジョブ番号 フォアグラウンド実行に変えるbg ジョブ番号 バックグラウンド実行に変えるctrl c キャンセルctrl z 中断（再開できる）crontab -e 編集crontab -l 確認sudo service cron restart 再起動systemctl status cron 稼働の確認30 12 * * 0 python3 /home/app_hoge/main.py cronはバックグラウンド実行でnohup &を含めると実行されない、多分top プロセス/CPU/メモリ等の情報、こちらで動いていればpsのstatがsでも問題ない、多分ps auxps f -A プロセスをツリーで表示し便利kill -lkill -SIGCONT プロセス番号sudo less /var/log/cron.logsudo tail -f /var/log/cron.logsudo less /var/log/syslogsudo tail -f /var/log/syslog
■ディスク系
ext4 一般的なデスクトップやファイルサーバ向け、16TBまで、ファイルシステムチェックで遅いxfs 高負荷IOで大容量データ処理向け、ジャーナルなし、ファイルシステムチェックを短縮論理ディスク＝パーティション
/dev/sda1, /dev/sda2, /dev/sdb, /dev/sdf等、数字はパーティション番号、数字がないとパーティション1つだけ
ディスク拡張
lsblkdf -Thdu -sk * | sort -nr
#xfsの場合pvdisplaypvresize /dev/nvmvgdisplaylvdisplaylvextend -l +100%FREE /dev/vg001/lv001xfs_growfs /opt
#ext4の場合apt autoclean キャッシュあるがインストールされていないdebファイル削除apt autoremove 必要なくなったパッケージ削除disk -l /dev/nvm パーティション情報growpart /dev/nvm 1 指定パーティションの容量拡張resize2fs /dev/nvm ファイルシステム拡張
容量調整
/var/cache はapt-get clean, yum cleanで消す程度で
■swapをrootからvarに移動freeswapon -aswapを無効化swapoff -v /swap.extendedswapをvarに移動mv /swap.extended /var/etc/fstabからswapのエントリを/varに書き換えcat /etc/fstabswapを有効化swapon -a確認free -h
■ライブラリアップデート
sudo apt updateapt list --upgradable | grep mysql
sudo apt install mysql-client=6.6.6-0ubuntu2.1~99.99.9sudo apt install mysql-client-core=6.6.6-0ubuntu2.1~99.99.9
…
dpkg-l | grep mysql
■WSL2https://qiita.com/zakoken/items/61141df6aeae9e3f8e36https://qiita.com/SAITO_Keita/items/148f794a5b358e5cb87bWSLインストール後はネットワークの設定が必要なら例) apt updateが出来ないWSL のバージョンはユーザの設定依存のため、version 2 (WSL2) が必要ならコマ ンドプロンプトで以下のコマンドを実行wsl --set-default-version 2アプリからWSL起動、CMDやPowershellならwslで起動 wsl --shutdown で停止 設定したユーザディレクトリにアクセスする(それぞれ別の場所)• WSLからは /mnt/c -> /mnt/c/Users/ore/Desktop/github• WINからは \\ws/$ -> \\wsl.localhost\Ubuntu-22.04\home\oreNW設定: WSL2のデフォルトでは起動するたびにWindowsホストのDNS設定を基にして自動的に/etc/resolv.conf を生成するが、サーチリストはWindows側から引き継がれないうえ、意図しないタイミングで勝手に再生成されてしまうので停止するnano/etc/wsl.conf下記追記[network]generate ResolvConf = falseDNS設定sudo unlink /etc/resolv.confsudo nano /etc/resolv.conf以下のように設定nameserver 172.27.117.yynameserver 172.27.117.xxsearch in-xxx.com dns search list.xxx.comproxy設定nano-/profile以下の設定を既存プロキシの下に追加export http_proxy="http://proxy:3128"export https_proxy="http://proxy:3128"apt の proxy 設定sudo /etc/apt/apt.conf以下のように設定Acquire: http: Proxy "http://proxy:3128",Acquire: https: Proxy "http://proxy:3128";WSL2を抜け、WindowsコマンドプロンプトでUbuntu を再起動ore@unco-017:/mnt/c/Users/ore$ exit
rootでキーを作成するとgithub上でユーザがrootとなるsudo adduser aaasudo usermod -aG sudo aaasudo nano /etc/wsl.conf 下記を追記しwsl再起動whoami[user]default-aaaecho $HOMEcd-mkdir.sshssh-keygen sudoだとgithubログイン時に名前がrootになってしまう/home/aaa/.ssh/id_rsacd- /home/aaanano/home/aaa/.ssh/configHost github.comHostName ssh.github.comPort 443ProxyCommand connect-proxy -H proxy:3128 %h %puser gitchmod 600 configeval "$(ssh-agent-s) sshエージェント起動ssh-add/home/aaa/.ssh/id_rsa sshエージェントに鍵を登録ssh-add確認初回は接続yesをして Warning: Permanently added (ssh.github.com): 443 (ED25519) to the list of known hosts.
wal-d Ubuntu-22.04 -u root パワシェルでrootユーザに切り替える場合wal.exe-shutdown パワシェルでシャットダウンや再起動の場合
パッケージの更新sudo apt update && sudo apt upgrade -yWSL環境設定cd /home/oreは/rootを表す(/homeでない)sudo apt install connect-proxy/rootにキーを生成ssh-keygenpassphrase xxXXcat /root/.ssh/id_rsanano/root/.ssh/configHost github.com HostName ssh.github.com Port 443 ProxyCommand connect-proxy -H proxy: 3128 %h %p user omecochmod 600 configシンボリックリンクを生成するcd /home/oreIn-s-/sshGithubサイトのユーザ設定でpub keyを登録し、承認するcd /mnt/c/Users/ore/Desktop/githubgit clone git@github.com:oreore/xxx.gitping github.com で通信確認ができる
curl https://sdk.cloud.google.com | bashexec -1 $SHELLgcloud auth application-default loginURLコピペgcloud config configurations listgcloud config configurations create kusogcloud config set account xxx@xxx.comgcloud config set project project-xgcloud config configurations activate kusogcloud auth loginpyenv install 3.13.0pipenv-python 3.13.0gcloud components updategcloud components install cbt(BigTable例)(パスフレーズを省略できる) eval $(ssh-agent); ssh-add-/.ssh/id_rsatfenvをマニュアルインストール https://github.com/tfutils/tfenvtfeny install 1.00.0tfenv listtfenv use 1.00.0export TF_CLI_ARGS_plan="-parallelism=50"export TF_CLI_ARGS_apply="$TF_CLI_ARGS_plan"環境変数を変更した場合は source ~/.bash_profile を反映
■SPFspfレコードはメールを送信する際、送信元サーバとDNS上のIPアドレスを比較自社から取引先に送信したメールにSPFレコードを設定していなければ、相手側のメールサーバで迷惑メールとされ届かない場合も
送信元のDNSに送信元IPをSPFレコードに登録する（ドメインをSMTPのIPに変える？ドメイン IN TXT v=spf1 ip4:172.16.0.1 -all(+が省略されているがIP許可、allを認証しないという意味）送信側SMTPサーバではSPFをチェックせず何でも送信
受信側MTAにて設定され（SMTPにはトランスファのMTA、デリバリのMDAspfを使えば先方がspfレコードを登録していなければメールが受け取れないpostfixやeximのSPFをonにする設定がある
spfレコードが設定されているかを確認nsookup -type=TXT 調べたいドメイン
■lsofはオープンファイルの略だがネットワークソケットの調査
lsofでファイルを開いているプログラムを特定する | 晴耕雨読 (tex2e.github.io)lsofコマンド入門 #Linux - Qiita
＝＝＝＝＝＝＝＝＝＝＝＝＝
■VS code
マルチカーソル：ctrl+shift+↓
[Alt]+クリックカーソルを追加[Ctrl]+[Alt]+[↑]/[↓]カーソルを上下に追加[Ctrl]+[U]カーソル操作を元に戻す[Shift]+[Alt]+[I]カーソルを行末に追加[Ctrl]+[L]行を選択[Ctrl]+[Shift]+[L]選択中の文字列と同じものをすべて選択[Ctrl]+[F2]カーソル位置の単語と同じものををすべて選択[Shift]+[Alt]+[→]選択範囲の拡大[Shift]+[Alt]+[←]選択範囲の縮小[Shift]+[Alt]+ドラッグ矩形選択[Ctrl]+[Alt]+[Shift]+[カーソル]矩形選択[Ctrl]+[Alt]+[Shift]+[PgUp]/[PgDn]矩形選択 ページ上下VSCodeのマルチカーソル練習帳 - Qiita
マルチカーソルを使わないVSCodeはただのVSCodeだ！〜解説編〜 - memo_md (hateblo.jp)
続き
/// BANGBOO BLOG /// - Linux cmd2
Comment (0)
Navi: < 11 | 12 | 13 | 14 >
-Home
-Column [128]
-Europe [9]
-Gadget [77]
-Web [133]
-Bike [4]
@/// BANGBOO BLOG ///
