何も考えず mysql をすぐに用意する方法
docker run --name instant-mysql -v ${PWD}/data:/var/lib/mysql \
-p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -e TZ=Asia/Tokyo \
-d mysql:5.7 --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
接続方法は以下の通り
mysql -u root -ppassword -h 127.0.0.1
まずは berw を最新にする
brew update
git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask fetch --unshallow
php 8 が brew コマンドでインストールできることを確認
brew search php@8
mac に php 8 をインストール
brew install php@8.0
vi ~/.zshrc
export PATH=$PATH:/usr/local/opt/php@8.0/bin:/usr/local/opt/php@8.0/sbin
source ~/.zshrc
php -v
curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer
composer -V
Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 83886080 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/RuleSet.php on line 90
Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.
PHP のメモリーが少ないためのエラー
composer の場合、COMPOSER_MEMORY_LIMIT を先頭につけることで回避可能。
`COMPOSER_MEMORY_LIMIT=-1 composer require auth0/auth0-php`
Mac の docker の version が低い可能性がある。
version up することで問題は解消された。
update 方法は以下のブログにあるファイルをダウンロードし、展開するだけ
https://docs.docker.com/desktop/mac/release-notes/
現在の PHP の memory_limit を確認
php -r "echo ini_get('memory_limit').PHP_EOL;"
128M
php.ini を確認する
環境によっては複数の php の version が入っていることもある。
% sudo find / -name php.ini
/usr/local/etc/php/7.2/php.ini
/usr/local/etc/php/7.3/php.ini
/usr/local/etc/php/7.4/php.ini
/usr/local/etc/php/8.0/php.ini
php の version を確認し、あたりをつける。
% php -v
PHP 7.3.11 (cli) (built: Jun 5 2020 23:50:40) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies
php 7.3 のようなので、設定ファイルは
/usr/local/etc/php/7.3/php.ini ではないかと推測
設定を確認すると、128M ということを確認できた。
上限を取り除くには
memory_limit = -1
に変更する。
composer の場合
COMPOSER_MEMORY_LIMIT=-1
を先頭に追加してコマンドを実行することで回避できる
COMPOSER_MEMORY_LIMIT=-1 laravel new sample-project
「kms:ViaService を利用して、CMK を呼び出していない時」というポリシーの書き方をすることができる
"Null": {
"kms:ViaService": "true"
},
この部分は Classmethod さんのブログが非常にわかりやすい
https://dev.classmethod.jp/articles/ebs-kms-sourceip/
kms:ViaServiceは、CMKの使用を指定のAWSサービスからのリクエストに制限する条件キーであり、
Nullは、条件キーの存在を確認する条件演算子を指す。
Nullで {"kms:ViaService": "true"}と指定すると、「kms:ViaServiceが存在しない（≒CMKを呼び出していない）」という条件になる。
これを接続元IPアドレスを制限する条件に追加することで、「CMKを呼び出していない かつ 接続元IPを制限する」という条件になる。
直感的に Webページを作る NoCodeツールです。
Product Huntで、2021年9月9日週のランキングで1位を獲得しています。
日本語で詳しい説明はtakuya hayashiさんがされているので、詳細はそちらをご覧ください。
https://note.com/woods0918/n/n7d6364519146
さまざまな NoCode ツールは発表されていますが、upflowy はどのような特徴をもっているのか実際に触って調べてみましたので完結にまとめました。
これ自体は他のWebサービス同様、ポチポチと済ませます。
navi が教えてくれます。現在は日本語対応していません。
いくつかのテンプレートは用意されていて、自由に選ぶことができます。
無料アカウントではDB 接続ができません。
そのため、ログイン画面で入力されたID/PW を IF 文でただの文字列として判断し、照合できたらログイン後のページを出すためだけの画面をつくりました。もちろん、ログイントークンとかもなにもないただの判定するだけのページです。
サンプルで作ったフローは以下の通りです。
判定ロジックはこんな感じにしました。ただの判定です。
できたページが以下の通り
サンプルページを公開します。ご自由にいじってみてください。
https://my.upflowy.com/sqr-tsukada-test
ID/PW は以下の通り
test@sumito.jp
password
現在は最低限の機能のみに絞られていて、上記ページの作成だけであれば学習時間込みでも 30分で作れました。
これについてはどこにも記載がないので、直接聞いてみた。
どうやら現時点では upflowy からのアウトバウンドIP を限定することができず、API 側で IP 制限がかかっている場合ひっかかってしまいそうです。
パスワード入力画面は、パスワードがそのまま画面に表示されるのではなく、せめてアスタリスクなどでマスキングされた状態で画面に表示して欲しい。
いじってみたところそれができなそうだったので、直接聞いてみました。
こちらは現在開発中の機能で、現在使えないようです。
アンケート画面を作ったり、Mock を作ったりという利用では十分使えるのではないかと思いました。
しかし、Webページを作るにはまだまだ機能が不十分という印象を感じです。
アップデートの予定はある様なので、今後に期待したいと思います。
あまり日常的に触らないサービスの１つである。
何度もこの違いについて過去に調べてはいたが、使わないものは忘れてしまう。
メモがてら残す。
https://aws.amazon.com/jp/inspector/
また、脆弱性チェック対象のインスタンスは、エージェントをインストールする必要がある。
https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/
の5つの項目について、チェックすることが出来るツール。
それぞれ１行でまとめると
AWS Inspector は脆弱性検知することが必要でエージェントが必須
AWS Trusted Advisor は AWS のベストプラクティスに沿って作られているかスキャン、レポーティングしてくれる機能
と考えておけば良さそうだ
{
"Id": "xxxxx",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "xxxxx",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::hoge-hoge",
"Principal": "*"
}
]
}
この設定をしていて アクションはステートメント内のどのリソースにも適用されません とエラーが出る
原因は、バケットのみ Resource として指定しているためであり、この問題を解消するには
"Resource": "arn:aws:s3:::hoge-hoge/*",
のようにバケット内のどのオブジェクトにアクセスを許可するかを必ず指定する必要がある。
AWS 管理のCMK は我々ユーザーで管理することはできないが、 3年ごとに自動でローテーションされる
AWS 管理の CMK AWS 管理の CMK のキーローテーションを管理することはできません。AWS KMS は AWS 管理の CMK を 3 年ごと (1095 日) に自動的にローテーションします。
https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/rotate-keys.html
なお、我々ユーザーが管理する CMK は 365 日に設定されている
キーの自動ローテーションを有効にすると、AWS KMS は有効にした日から CMK を 365 日ローテーションし、その後は 365 日ごとにローテーションします。
https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/rotate-keys.html