【AWS CLI】An error occurred (InvalidAccessKeyId) when calling the PutObject operation:エラーの解消
事象
EC2のインスタンス上からAWS SAMのデプロイをしようとしたところ、以下のようなエラーが発生。
An error occurred (InvalidAccessKeyId) when calling the PutObject operation:
いつもはEC2にIAM roleをアタッチしていてそれを使ってデプロイしていたのですが、いきなりエラーがでてデプロイできなくなりました。
原因
色々調べたところ、aws configureコマンドで.awsフォルダ含めてcredentialファイルを生成してしまったことにより、IAM roleを使えなくなってしまったことが原因でした。
対応
.awsファイルごとcredentialファイルを削除してあげます。
rm -r .aws
これだけで動くようになりました。
aws configure list
コマンドを打って、IAM roleでAWSにアクセスするようになっているか確認できます。
以上です。
図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書
- 作者:小笠原 種高
- 出版社/メーカー: 技術評論社
- 発売日: 2019/11/07
- メディア: 単行本(ソフトカバー)
AWS SAMのための開発環境をDockerで構築する
最近AWS SAMを使い始めたので開発環境構築について書いてみたいと思います。
今回作成する環境はこんな感じです。
- lambda実行環境であるamazonlinux環境をDockerで作る
- docker-composeしてVSCodeのRemote Containerでアクセスする
実際のサーバーレスアプリは次回作成してみるとして、今回はここまで作ってみます。
なお、macの環境で作っていますが、docker volumeを使うのでwindowsでも同じように作れるはずです。
ローカルにDockerの準備をする
Docker for macはインストール済みという前提で進めます。インストールしていない人は先にインストールしてください。インストール後、ローカルの自分の好きなディレクトリで以下コマンドを打ってください。
$ mkdir amznlinux $ mkdir amznlinux/.devcontainer $ touch amznlinux/docker-compose.yml $ touch amznlinux/Dockerfile $ touch amznlinux/.devcontainer/devcontainer.json
こんな感じのツリー構造になっているでしょうか。
├── amznlinux │ ├── .devcontainer │ │ └── devcontainer.json │ ├── Dockerfile │ └── docker-compose.yml
続いて、それぞれのファイルの中を記述していきます。
まずDockerfileにはユーザーを作成し、aws-cli、aws-sam-cliのインストールをしていきます。
また、インストールにあたりlinuxbrewを使っていますので、まずそれをインストールします。
そのあたりの手順は公式に書いてありますので、それをベースに作っています。
FROM amazonlinux:2 RUN yum update -y RUN yum install -y git tree tar sudo bzip2 gcc-c++ make wget e4fsprogs RUN yum clean all # ユーザを作成 RUN useradd awsuser && \ echo "awsuser ALL=(ALL) ALL" >> /etc/sudoers && \ echo "%wheel ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers && \ gpasswd -a awsuser wheel #localeとタイムゾーンの設定 RUN yum reinstall -y glibc-common RUN cp /usr/share/zoneinfo/Japan /etc/localtime RUN echo "export LANG=ja_JP.UTF-8" >> /home/awsuser/.bash_profile #Docker install RUN amazon-linux-extras install docker # Linuxbrewのインストール USER awsuser RUN sh -c "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install.sh)" RUN eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv) RUN echo "eval \$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" >>~/.bash_profile ENV PATH $PATH:/home/linuxbrew/.linuxbrew/bin # awscliとaws-sam-cliのインストール RUN brew install awscli RUN brew tap aws/tap RUN brew install aws-sam-cli USER root
docker-composeファイルは非常にシンプルな構成です。
なお、冒頭でもあったようにdocker volumeを使っていますので、volumesを定義します。
version: '3.7' services: amznlinux: build: . command: /sbin/init privileged: true volumes: - amznlinux:/home volumes: amznlinux: external: true
最後にVSCodeのRemote Containerを使用するための設定ファイルになります。
lambdaの開発にはpythonを使う想定なので、pythonの拡張機能を追加しておくと良いと思います。それ以外はお好みで必要な拡張機能を追加してください。
{ "name": "AmazonLinux", "dockerComposeFile": [ "../docker-compose.yml" ], "service": "amznlinux", "workspaceFolder": "/home", "extensions": [ "ms-python.python" ] }
Dockerの事前設定
ファイルの準備ができたら実際にDockerを構築していきましょう。
まずはdocker pullでイメージを取得します。そして、amznlinuxというdocker volumeを作成し、そこにデータを永続化するようにします。
docker pull amazonlinux:2 docker volume create amznlinux
完了したら、先ほど作成したDockerfileとdocker-composeファイルを使ってdocker-compose buildをします。
docker-composeするときはdocker-compose.yml配下のディレクトリに移動することに注意。
cd amznlinux docker-compose build
5分くらいかかると思います。
Successfully built
と表示されたら完成です。
VSCodeのRemote Container準備
続いてVSCodeを開き、拡張機能で「ms-vscode-remote.remote-containers」と検索してください。
これをインストールします。
インストールが完了したら左下に以下のボタンが表示されていると思います。
緑のところをクリックすると、画面上部に以下のコンソールが出ますので、
「Remote-Conteiners: Open Folder in Conteiner...」をクリックします。
出てきたファインダーで、amznlinuxのディレクトリを選択して、開くをクリック。
すると自動的にリモート接続されます。うまくいけば以下のような画面になるはず!
あとはVSCode上のターミナルで、AWS CLIとAWS SAM CLIがインストールされているか確認してみてください。
su - awsuser aws --version sam --version
以上で開発環境の構築は完了です。あとはsam initなり、git cloneなりして開発を始められると思います。
【3歳児】ワタシハカタカナチョットデキル
最近3歳になった娘ですが、割と文字を読むのが上手です。
2歳過ぎた頃から少しずつひらがなを読み始め、1文字づつであれば2歳半にはひらがなが全て読めるように。
そして3歳になった今、カタカナも完全コンプリートしました。それどころか、簡単な文章であれば続けて読むこともできるようになってきました。
保育園が割と知育に力を入れているので、同じクラスの子も結構読めるみたいですが、うちの子は早生まれなのにすごい!(親バカ)
例えば、今日なんかも保育園に飾ってあった雛人形の下に「さわらないでね」と大きくひらがなで書いてありました。
お迎えに行って、その前を通り過ぎる時、娘が自然に「さわらないでねって書いてあるね」と言ってきました。
その通りだ。娘よ。
「そうだね、壊れちゃうから触っちゃダメだね。」
と軽く流しましたが、サラサラーと読んでみせたことに後になってちょっと驚き。
週末、デパートに出かけたり、お出かけすると読める文字は「〇〇って書いてある」と報告してきます。
なんなら道路に書いてある「止まる」も読めます。「福音館書店」も読めます。おっと、これは雰囲気で読んでる説。
「ブロンズ新社」も「ふくいんかんしょてん」って読んでたことがあるので・・・
教えたら教えただけ読めるようになる。その吸収力が僕も欲しい。
家ではほとんど毎日夜寝る前に読み聞かせをしています。最近は逆にパパに読み聞かせをしてくれることもあって、その練習の成果でしょうかね。
もうちょっと大きくなったら百科事典を買ってあげます。
楽しみです。
【Docker】"exec: \"tar\": executable file not found in $PATH": unknownエラーが出た
docker-composeしようとしたらハマったのでメモ。
事象
macを使用。
VSCodeからRemote Containerを使ってDockerにアクセスしようとしたら以下の文言が出てエラーとなった。
starting container process caused "exec: \"tar\": executable file not found in $PATH": unknown
ググってもなかなか出てこない。
エラー内容をよくみてみるとtarがうまく使えていない模様。
そこで「mac tar」あたりでググると以下のありがたい情報に行き着く
Mac にバンドルされている tar コマンドは、GNU の tar とはオプションが異なり、Mac と Linux で挙動が変わってしまいます。
なにっ!?
対応
ということで、gnu-tarをインストールして、PATHを通しました。
brew install gnu-tar export PATH="/usr/local/opt/gnu-tar/libexec/gnubin:$PATH"
改めてtar --version指定みたところ、
tar (GNU tar) 1.32 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason.
ちゃんとgnu-tarが入っていますね!
いざ、再度実行!
無事、Remote Container立ち上がりました〜。
思わぬところでハマってしまった。
プログラマのためのDocker教科書 第2版 インフラの基礎知識&コードによる環境構築の自動化
- 作者:WINGSプロジェクト阿佐 志保
- 出版社/メーカー: 翔泳社
- 発売日: 2018/04/11
- メディア: Kindle版
エンジニアに転職してドライアイが加速した
エンジニアに転職して2ヶ月、働き方やスキルについて変わったことが多いですが、身体面でよくない方向に変わったことがあります。
そう、目がツライ。
もともとドライアイでパサパサになりやすく、朝起きたら目が乾いて開かないことがあったりしていました。
それが悪化しました。
それもそのはず、前職SIerでは打ち合わせに出ることが多く、PC作業が中心とはいえ、1日でずっとPCを見ているということはありませんでした。それが今では全く打ち合わせがなく、会話もSlackが多くて言葉を発する量も以前と少なくなっています。その分、ずっとPCを見ているのでもう目がツライです。
具体的には、頭痛になって現れました。転職して1ヶ月くらいでなぜか頻繁に頭痛になるようになりました。それまでは年に数回というレベルでしたが、軽めの頭痛が1週間続くような時もありました。最初は何が原因かわからず苦しみましたが、「あ、目だわこれ」と気がついてからいろんなことを試し、今は収まっています。
頭痛対策 試したこと
目薬
まずは目薬を使う量を増やしました。そしてドライアイ専用の最近CMで見ていたロート製薬のこちらを購入。
会社近くのドラッグストアで買ったら1600円オーバーだったんですが、Amazonなら1100円くらいなんですね。
今は午前中2回、午後3回くらいで1時間に1回くらい使っています。使用方法を見ると、
用法・用量 1回1~3滴,1日5~6回点眼してください。
と書いてあるので、限界まで使っていることになります。
ドライアイって、自分では乾いているかわからないことがあるんですよね。なので、トイレ休憩に立った時とか、時間を見て意識して点眼するようにしました。
ホットアイマスク
次に試したのが、ホットアイマスクです。最初はこちらのめぐりズムの一番よく見るやつ。
寝る前にこれをつけて寝落ちするということが頻発しました。気持ちいい。でもこれだとすぐになくなってしまうので家計によくありません。
一箱使い終わったタイミングで、こちらに移行
リラックスゆたぽん ほぐれる温蒸気 目もと用 ・あずき+セラミックのたっぷり蒸気
- 発売日: 2017/09/01
- メディア: ヘルスケア&ケア用品
中に小豆が入っていて、レンジでチンして温めるタイプ。なんと365回も使えるとのこと。これであれば家計の負担にもなりにくい。めぐリズムの蒸気でアイマスクよりも重さがあって、個人的には目にしっかり暖かさが伝わるのでこちらの方が良かったです。
毎日かかさずにやってます。
画面を黒く黒く
できるものは全部ダークモードで使うようにしました。VSCodeは標準でそうなっていますし、Chromeも枠の部分は黒くして、とにかく画面が光らないようにしてます。これは単体で効果がどのくらい出ているかわかりませんが、気持ち的な問題ですね。
結果
頭痛はよくなりました。ただ、目の乾きが改善したような気はしませんし、パサパサ感はずっと残っていますが少しずつ改善させたいです。真面目に眼科に通ってちゃんとした目薬もらったり、ブルーライト防ぐメガネ買ったりしようかな。
エンジニアの皆さんにおかれましてはどのように目の管理をしているのでしょうか。
今回は以上になります。
金融系SIerからWeb系エンジニアに転職して2ヶ月が経った
12月に金融系のSIerからWeb系企業に転職して2ヶ月ほど経ったのでブログを書いてみようと思います。
SIerからの転職エントリはたくさんあれど、そこから生き残っているという話が少ないというのを耳にして、自分は運よく生き延びてますという話です。このままいけば試用期間で切られることはなさそうです。本当に運がよかった。
前職について
前職はいわゆるユー子でした。SIerピラミッドの元請け、あるいは0次受けと言って通じるでしょうか。
そこで9年くらいSIerとして仕事をしていました。前職の最終的な職種は?と聞かれたら自分は「エンジニアではなく、プロマネ兼ビジネスアナリストです。」と答えます。システム開発のプロジェクトに関わっていましたが、最後の5年くらいはプログラムを自分で見たり触ったりすることはなく、要件をまとめ、プロジェクトを管理し、交通整理をしてプロジェクトを前に進める仕事が中心でした。
VSCodeもGitも入っていない、3ギガのメモリを積んだPC上で、エクセルとパワポとメールをひたすら使って、調整、調整、調整。打ち合わせ、打ち合わせ、打ち合わせの毎日です。残念ながら、僕の力量不足もあって、プロジェクトが円滑に進んだことはなく、常に何かしらの問題が発生し、それをなんとかユーザー、協力会社の方の間に入って調整していくという仕事です。ただ、超絶ブラックというほどではく、月の残業時間は60時間〜70時間を前後するという感じで、残業代もちゃんと出ていたので給料はそこそこあったと思います。
プロジェクトを前に進める役割を持っているのは当社の社員なので、億を超える案件をステークホルダー計50名くらいまとめながら推進していく仕事というのはそれなりに価値のある仕事だと思いましたし、給料も年功序列ながら10年後はそれなりにもらえるなという先輩方の背中がありましたので、このまま会社に残るという選択肢もありました。が、転職を決意して転職しました。
転職理由
大きく2つあります。
一括請負つらい
SIerがネット上で悪口を言われてることの多くは、構造上の問題だと思っています。そしてその構造は業界全体で支えているものであり個人の力ではどうしようも無いということ。
元請けとはいえ、「請け」な構造は変わりません。プロジェクトベースの仕事、即ちそこには有期で達成しなければならない目標があり、限られたお金があり、限られた人しかいません。
ウォーターフォール型でかっちりできればいいんでしょうが、要件定義時に業務の全てを網羅的にドキュメント化することは不可能で、どこからともなく「アジャイル要素を入れて」とか何とか言われ、仕様変更は当たり前。
「でも期限は守ってね♡」
協力会社も請負契約なので守るべきところは守ってくる(当たり前)ので、元請けの仕事は、ユーザー無茶な要求変更を退け、協力会社さんに無茶をお願いしてまわる、というのが基本的な「調整」の中身になります。
この構造は、一括請負で働く以上は変わらないし、この「調整」をあと30年やっていくのか…と考えたらつらくなりました。
特に最後に担当していたプロジェクトはメテオフォール型開発で、下民の私にはなすすべなく疲弊していきました。プロジェクトマネジメントをしろと言われて、実態はヒトもお金も期限も自分のコントロール下にないという状況が辛かったです。
もちろん、上手くやっているプロマネの方はたくさんいましたし、尊敬していました。
「それが面白いところでしょ!」と言われれば私には適性がなかっただけとも思います。
プログラム書くの楽しい
会社ではプログラミングのプの字もなかったので、プライベートでプログラミングをしてました。phpでまとめのアンテナサイトをフレームワークなしで作ってみたり(その頃はフレームワークという概念を知らなかった)、Rubyのgemを作ってみたり、Androidアプリを作って公開してみたりしました。
どれも別に誰かに使って貰えた訳じゃないですが、手広く色んな言語に触れて、プログラミングの楽しさ、奥深さを感じていました。
それでも、残業が増えたり、子供が産まれたりする過程で自分の時間が消え、家でプログラミングする時間がほとんど取れなくなっていきました。
このままこの会社で耐え忍んで30年過ごすか、エンジニアに転生するか、結論は正直入社して数年で決まってたんですが、プライベートのタイミングが合わなくて、そして担当プロジェクトのキリの良いタイミングを見ていたら30歳を超えての転職となりました。
転職活動
「転職は縁」とはよく言ったもので、運良く縁に恵まれました。
事業が面白そうなところ、直近でプライベートで学んでいたRailsやGoを使った開発ができるところを中心にエージェントに選んでもらって、トントン拍子で話が進み、1ヶ月ほどで転職活動を終了することが出来ました。
実務未経験での転職なので年収は当然下がる想定で元々考えていて、結果としても100万円ほど下がる形でオファーを受けました。
ただこの金額は他の併願していた企業よりも圧倒的に高く評価してもらえた結果で、正直前職で残業しなければこのくらいになるので、大満足の額でした。
転職して2ヶ月で何をしてきたか
今はRailsを中心に担当してます。この2ヶ月で何をしてきたか振り返ってみます。
まず入社して初めにやったことは開発環境の構築です。Docker上に環境を構築するのですが、勉強としてdockerfileを1から作るところから始まりました。
Dockerの存在は知ってましたし、プライベートでちょっとだけ触ったこともありましたが、実際にdockerfileを作ろうとすると、全くお作法がわかりません。ほとんどゼロ知識から始めて、最初に環境が立ち上がってrails sするのに3日、そこからdockerfileの中身を綺麗にして、docker-composeファイルを作って、VS Codeのremote containerでアクセスするまでに更に3日くらいかかりました。
結果として、ゼロからエラーを解消しながら構築したことで、dockerfileで何をやっているのか、compose, volume, networkなど基本的な構造を理解することが出来ました。
続いて現行サービスの理解です。ドキュメントはそんなに整ってなかったので、メンターの方にシステムの全体象とざっくりの業務フローを教えて貰った後、ソースコードをみて、画面を見てを繰り返しながらサービスの知識とデータの流れを抑えていきました。特に他システムとAPIで連携しているところなんかは、プライベートでもやってこなかった所なので理解するのが大変でした。
前職では、データ連携といばCSVのファイル転送とバッチジョブでしたが、今はRESTでAPIで中身はJSON形式です。日々、前職との違いをひしひしと感じながら一人楽しんで学ぶことが出来ました。
だいたい1週間くらいはただひたすら読んでいたと思います。読みながら、画面遷移図を作ったり、業務フローを作ってみたりしました。
この頃からPlantUMLというものを知り、積極的に覚えて使いました。
前職のExcelとパワポ中心の生活が、Markdown中心の生活に変わり、ここでも転職したんだなあという実感が湧いてきました。
そういえばメールも前職では1日に30通くらい書いてましたが、今ではSlackでのやり取りが多く、メールは1週間に数回というレベルです。凄い変わりようです。
さて、そのあとはRSpecの勉強をしました。読めて書けるようにならなければいけません。幸いテストコードは沢山あったので、とにかく読んで実行してを繰り返しました。
ある程度、RailsもRSpecも読めるようになったのが入社して1ヶ月ほど。
そこからは小さなバグだったり、機能改定だったりを少しづつ貰って、実装、テスト、レビューを繰り返しました。
gitを仕事で使うのはもちろん初めてでしたが、これもプライベートで1人プルリクとかをやっていたおかげか、今のところ事故らずに生きてます。
新しい会社での開発のお作法が少しずつ分かってきたところで2ヶ月が経ちました。
今後は勉強会にも参加しながらrubyの真髄をしっかり身につけてレベルアップしていきたいと思います。
働き方
1日の可処分時間が10倍くらいになった気分です。前職ではメール、電話、打ち合わせで日中自分が作業に集中できる時間はありませんでした。定時を過ぎてから明日の説明資料を作ったり、管理表を更新したりする日々でした。
それが今や定例の打ち合わせは週に3時間だけ。あとは突発的な、数分で終わる打ち合わせを除けば、それ以外全て自分の作業時間です。捗りに捗ります。おかげで2か月前とは比べ物にならないくらい、技術的知識が着いた気がします。もちろん、まだまだ初心者なのでこれを積み上げていってそこそこのエンジニアにまずはなれるように頑張ります。
あと、残業はほとんどありません。たまに保育園のお迎えにも行けます。家族で夕飯を囲むのが普通になりました。控えめに言って最高です。
これからの展望
向こう3年は取り敢えず技術を頑張ってみようかなと思います。そこで自分の適性が見えてくるかなと思います。オブジェクト指向による抽象化の真髄、アルゴリズム、メモリ管理など、技術者として普遍的な知識を中心にまずは進めていきたいと思っています。
事業も面白いし、周りの人も良い、エンジニアとしてはたらく環境も良い。モチベーションも自然と高くなります。息切れしないで突っ走れたらいいなと思ってます。
また、転職して半年くらいしたら状況を書いてみようと思います。
今日はこのくらいです。
ABCのA問題全埋め
AtCorderを細々と始めました。
何度かABCのコンテストに参加してみたものの、灰色から抜け出せません。1時間半かけてたまにC問題が解けるくらいの雑魚です。B問題ではほとんど躓かない。
C問題を解くには簡単なifの条件分岐を脱して、基礎的なアルゴリズムの理解が必要。何も考えずにO(n^2)とかになって時間切れでACならず。
取り敢えず、B問題で時間が取られないようにABは全部過去問埋めておこうかなと思って3週間くらい書けてようやくA問題が終わりました。
家ではほとんど時間が取れないので仕事の昼休みの合間にちょこちょこと進めてました。1日に進められるのは最大でも10問くらいです。
今はB問題を始めてます。さすがにA問題よりは時間がかかるので、今のペースだと1日に5問が限界なので平日だけだと1ヶ月半くらいかかる計算になりますね。
B問題半分くらい解いたらアルゴリズムの本を買って通勤時間にでも読み進めるつもりです。
早くC問題サクッと解いてD問題に時間を使えるようになりたい。