2018年10月1日月曜日

Xcode10でビルドが通らない

毎度おなじみ
linker command failed with exit code 1 (use -v to see invocation)
が出ます。
~/Library/Developer/Xcode/DerivedDataを削除すると、大方のプロジェクトは治りましたが、c++のライブラリを使っているものが、治りません。

これは、Apple Developer Forumsで議論されていました。

Xcode 10 beta 4 - stdlibc++ headers not found;

簡単にいうと、Xcode10から libstdc++がなくなっちゃったということです。

仕方がないので、Xcode9にあったヘッダーとライブラリをコピーしました。

最終的にはlibc++に切り替えることが望ましいということなんだろうけど、
Podsで引き込んだライブラリをlibc++で使えるようにするのは、面倒なのでしばらく保留ですね。


AWSにメールサーバを立てる


1.Route53での設定


ドメインネームは取得済(購入済)で、運用中のものがあるものとします。
その前提で、今回はサブドメインを作成し、それをRoute53に登録しました。


もちろん運用中のDNSサーバにも、なんらかの設定が必要です。
私の場合DNSサーバはオンプレミスで運用しており、bind8での設定追加となりました(AWSではないので詳細略)。

で、話はRoute53に戻りますが、メール受信にはMXレコードが必要です。
が、それは手動で追加しなくても、次のSESで設定すればRoute53に自動反映されます。
ですので、Route53の設定はこれでおしまいです。

2.SESでの設定


現状東京リージョンには存在しないので、アメリカのリージョンでの作業になります。
(このことが後々まで面倒を引き起こすのですが…)
Domainsには既にRoute53で設定したものが存在しているので、もうメールは受信できる状態です。
後は受信した時にどうしたいかをRule Setで登録します。
ここではLambdaで受けるものとして、話をすすめます。



3.Lambdaの作成


例えばこんな感じです。



4.CloudWatchでメールの受信を確認


Lambdaが吐いたログは、CloudWatchのログで確認できます。

実験としてはこれでおしまいでいいのですが、実務としてはこれからが問題です。
私の場合、東京リージョンにあるRDSにメールの本文を登録したいのですが、これが簡単ではありませんでした。

5.SNSで東京リージョンに飛ばす


「アメリカのSES⇒アメリカのLambda」では、アメリカのVPC(EC2, RDS...)にしかアクセスできないので、東京のLambdaに接続することが必要になります。
このためには、現状SNSを挟むしかないようです。
「アメリカのSES⇒アメリカのSNS⇒東京のLambda」

【処方箋】
1.アメリカのSNSでトピックを作成。
  実メールアドレスと結びつける必要はないので、これでおしまい。
  サブスクリプションのエンドポイントには、Lambdaとの結合後に、自動的に値が反映される。
2.東京のLambdaでトリガーとしてSNSを選択。
  arnの選択肢には、前項のアメリカのSNSは出てこないで、コピペでarnを打ち込む必要あり。

ちなみにS3を介在させる案「アメリカのSES⇒アメリカのLambda⇒S3⇒東京のLambda」も模索しましたが、出来ませんでした。

6.RDSにはどうやってアクセスするの?


Lambda⇒DynamoDBはできるらしいですが、RDSにアクセスするのはいろいろと障壁がありました。
まず、Lambdaでどの(プログラム言語の)ランタイムを選択したかに大きく依存します。
そのランタイムが、データベースへアクセスするライブラリを標準で持っているかが問題となり、標準で持っていない場合には、デプロイといわれる作業で、ライブラリをインストールする必要があります。

私の場合は、Node.js(javascript)を選択し、RDSはOracleだったので、oracledbというライブラリをデプロイしました。
しかし、結果はご覧の通りで、動きませんでした。

module initialization error: Error
Cannot load /var/task/node_modules/oracledb/build/Release/oracledb.node
/var/task/node_modules/oracledb/build/Release/oracledb.node: invalid ELF header
Node-oracledb installation instructions: https://oracle.github.io/node-oracledb/INSTALL.html
You must have 64-bit Oracle client libraries in LD_LIBRARY_PATH, or configured with ldconfig.
If you do not have Oracle Database on this computer, then install the Instant Client Basic or Basic Light package from 
http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html

at Object.<anonymous> (/var/task/node_modules/oracledb/lib/oracledb.js:68:13)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/var/task/node_modules/oracledb/index.js:1:80)
at Module._compile (module.js:570:32)

Node.jsが動いているlinuxにnode-oracledbをインストールすれということでしょうか?
無茶なことをいいます。
しかし解決された方はいらっしゃるようです。
AWS Lambda (Node.js-v4.3.2)からOracleに接続する(ORA-21561への対応)

7.別な方法でRDSへアクセス


そもそもインラインで気軽に書けるということでNode.jsを選択した私なので、Node.jsゆえに苦労をするのはまっぴら御免。というわけで、node-oracledbの導入は諦めました。
現在EC2上で運用中のtomcatサーブレットに、Lambdaから必要なデータを渡すことにしました。
つまり「アメリカのSES⇒アメリカのSNS⇒東京のLambda⇒東京のEC2⇒東京のRDS」となりました。
せっかく読んでいただいた方には、何ともつまらん結論ですね。

8.よく考えたらNode.jsではなくJava 8を選ぶべき?


そもそもOracle使うなら、Node.jsではなくJava 8なんでしょうね。
Oracleが作ったものなのだから、標準でOracleにアクセスできないわけがない。
ただそうなるとインライン編集ができなくなるので、Lambdaを使う旨味がどんどん減っていく…感じはしますね。

世間では、Lambdaでどの言語を選択されているのでしょう? デファクトスタンダードは何なのか知りたいです。
Lambdaについては、いろんな選択肢よりも、むしろ「これを選択すれば大丈夫」というソリューションを一つ、提示してほしいですね。