20190318のNode.jsに関する記事は6件です。

Node.js で AES-256-CBC を使用した暗号化・複合

Node.js で AES-256-CBC を使用した暗号化・複合のサンプルです。

暗号化

function encrypt(algorithm, password, salt, data) {

    // 鍵を生成
    const key = crypto.scryptSync(password, salt, 32)

    // IV を生成
    const iv = crypto.randomBytes(16)

    // 暗号器を生成
    const cipher = crypto.createCipheriv(algorithm, key, iv)

    // data を暗号化
    let encryptedData = cipher.update(data)
    encryptedData = Buffer.concat([encryptedData, cipher.final()])

    return {iv, encryptedData}
}

複合

function decrypt(algorithm, password, salt, iv, encryptedData) {

    // 鍵を生成
    const key = crypto.scryptSync(password, salt, 32)

    // 複合器を生成
    const decipher = crypto.createDecipheriv(algorithm, key, iv)

    // encryptedData を複合
    let decryptedData = decipher.update(encryptedData)
    decryptedData =  Buffer.concat([decryptedData, decipher.final()])

    return decryptedData
}

サンプルコード

const crypto = require('crypto')

// AES アルゴリズム       
const ALGO = 'aes-256-cbc'

// 事前に共有すべきパスワード
// console.log(crypto.randomBytes(32).toString('base64'))
const PASSWORD = 'l+/MraaOI1yT3F1l15fJMcEKGiG3iWn7nOTmUS4fWk0='

// 事前に共有すべき SALT
// console.log(crypto.randomBytes(16).toString('base64'))
const SALT = 'kr3dJJ1mPcIKisMOR4RO6w=='

// 暗号化したいメッセージ
const MESSAGE = 'piyopiyo'


// 暗号化メソッド
function encrypt(algorithm, password, salt, data) {

    // 鍵を生成
    const key = crypto.scryptSync(password, salt, 32)

    // IV を生成
    const iv = crypto.randomBytes(16)

    // 暗号器を生成
    const cipher = crypto.createCipheriv(algorithm, key, iv)

    // data を暗号化
    let encryptedData = cipher.update(data)
    encryptedData = Buffer.concat([encryptedData, cipher.final()])

    return {iv, encryptedData}
}


// 複合メソッド
function decrypt(algorithm, password, salt, iv, encryptedData) {

    // 鍵を生成
    const key = crypto.scryptSync(password, salt, 32)

    // 複合器を生成
    const decipher = crypto.createDecipheriv(algorithm, key, iv)

    // encryptedData を複合
    let decryptedData = decipher.update(encryptedData)
    decryptedData =  Buffer.concat([decryptedData, decipher.final()])

    return decryptedData
}


console.log('MESSAGE:', MESSAGE)

// 暗号化したいメッセージ文字列を Buffer に変換
const data = Buffer.from(MESSAGE)
console.log('data:', data)

// 暗号化
let {iv, encryptedData} = encrypt(ALGO, PASSWORD, SALT, data)
console.log('iv:', iv)
console.log('encryptedData:', encryptedData)

// 複合
let decryptedData = decrypt(ALGO, PASSWORD, SALT, iv, encryptedData)
console.log('decryptedData:', decryptedData)
console.log('decryptedData(utf8):', decryptedData.toString('utf-8'))

メモ

  • 暗号化を行う側と複合を行う側で、事前に安全な経路で PASSWORD と SALT を共有します。
  • iv (initialization vector) は必ず毎回変わるようにします。
  • 暗号化を行う側から、複合を行う側に渡すのは、暗号化されたデータと iv です。
  • 暗号化されたデータと iv は安全でない経路で共有することが可能です。

Ref.

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Lambdaのスケジュール実行をローカルでテストしてみる

はじめに

AWSが公式で提供しているサーバーレスアプリケーションを構築するためのフレームワークである、AWS SAMを使うことにより、コードを書いてテストを行い、デプロイするまでを全てローカルで行うことができるようになります。
今回は、AWS SAMを用いてAWS Lambda Functionのスケジュール実行をローカル環境でテストする手順をメモとして残します。

環境

OS: macOS Mojave10.14
言語: Node.js 8.10
Docker: 18.09.2
SAM CLI: 0.11.0

環境構築

Dockerのインストール

AWS SAMはDocker上で動くのでDockerが必要。
以下の公式サイトからインストール。
https://docs.docker.com/docker-for-mac/install/

AWS SAM CLIのインストール

Homebrewでインストール。

$ brew tap aws/tap
$ brew install aws-sam-cli

プロジェクト作成

適当なディレクトリで、以下のコマンドを入力。
※samコマンドについては以下の記事が参考に。
https://qiita.com/gnk263/items/7f8796c26b9b61d33d96

$ sam init -r nodejs8.10 -n sample-app

すると以下のようなプロジェクトが作成される。

sample-app/
├── README.md
├── hello-world
│   ├── app.js
│   ├── package.json
│   └── tests
│       └── unit
│           └── test-handler.js
└── template.yaml

template.yamlの修正

Resources配下のHelloWorldFunctionを以下のように修正。スケジュールの実行間隔は任意に修正。
※Lambdaのスケジュール実行に関しては以下を参照。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/tutorial-scheduled-events-schedule-expressions.html

HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
        CodeUri: hello-world/
        Handler: app.lambdaHandler
        Runtime: nodejs8.10
        Events:
            Timer:
                Type: Schedule
                Properties:
                    Schedule: rate(1 minute)

ローカル実行環境構築用の設定ファイルを作成

sample-app配下で以下のコマンドを入力。

$ sam local generate-event cloudwatch scheduled-event > event_file.json

テスト

sample-app配下で以下のコマンドを入力。

$ sam local invoke "HelloWorldFunction" -e event_file.json

以下のような反応が返って来れば成功。

START RequestId: e832090d-203c-19f4-c6ae-580e00b3905f Version: $LATEST
END RequestId: e832090d-203c-19f4-c6ae-580e00b3905f
REPORT RequestId: e832090d-203c-19f4-c6ae-580e00b3905f  Duration: 13.40 ms  Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 30 MB  

{"statusCode":200,"body":"{\"message\":\"hello world\"}"}

終わりに

色々試したところ、template.yamlのScheduleの所にタイポがあっても成功レスポンスが返ってくるし、実際にCloudWatchに正しいスケジュール間隔で登録されるかどうかはデプロイしてみるまでは分からない模様。うーん。。。
指摘等ありましたらコメントお願いします。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

俺のオススメする監視ツール5選!!

監視ツール

監視ツールと一概に言っても色々種類あるのですが、今回はコマンド等で手軽に実行できるリソース監視ツールを紹介します。
一部、あまりオススメできないのもありますので、デメリット等よく読んでから利用してください。

  1. top
  2. htop
  3. ctop
  4. gtop
  5. conky

top

様々なOSにデフォルトで入っているかと思います。多分。

## 起動方法
$ top

ubuntu-top.png
↑こんな感じになります。

  • メリット
    • どのOSにも入っている(多分)
  • デメリット
    • macだとtopコマンド自体がリソースを喰う。windowsは未確認です
    • ↑僕のPCだと8〜15%ほどCPU消費してました

htop

topコマンドの強いバージョン。
こちらで紹介されているように、top使うくらいならhtop使いましょう。ってくらい良い感じのツールです。

## インストール方法
$ sudo yum install htop

## 起動方法
$ htop

htop.png

  • メリット
    • 導入が簡単
    • 見た目もよし
  • デメリット
    • 好きすぎて辛い

ctop

Dockerコンテナのリソース消費量を確認するのが楽。
稼働中のコンテナのリソース、選択した単体のコンテナの詳細リソースまでを表示してくれます。導入が楽なのもポイント高い。

## インストール方法
$ sudo wget https://github.com/bcicen/ctop/releases/download/v0.6.0/ctop-0.6.0-linux-amd64 -O /usr/local/bin/ctop
$ sudo chmod +x /usr/local/bin/ctop

## インストール方法(Macの場合)
$ brew install ctop


## 起動方法
$ ctop

ctop.png
↑コンテナ一覧(1つしかないけど)

ctop_2.png
↑対象コンテナをEnterで選択で詳細モード

  • メリット
    • 手間をかけずに導入できる
    • brewでmacにインストールできる ←ご指摘いただきありがとうございます!
  • デメリット
    • Linux用のバイナリなのでMacでは動作しない。 docker stats などを使いましょう

gtop

グラフィカルな感じにリソース監視等ができます。
Node.JSで動作してるようなので自分好みにカスタムできそうです。

## インストール方法
$ npm install gtop -g

## 起動方法
$ gtop

gtop.png
↑グラフィカルな感じがいい感じ

  • メリット
    • Nodeが入ってたら手軽に導入できる
    • グラフィカルな感じがいい感じ
  • デメリット
    • Nodeが入ってる前提なので入ってない場合導入ダルい

カスタム・自作方法はこちらを参考にしてみてください。

conky

ラズパイとかUbuntuで動かしてました。
導入方法とかは忘れたのですが、自分好みにカスタマイズできるので、興味ある方は是非。

https://github.com/brndnmtthws/conky

まとめ

監視ツールって導入が大変だったり、設定が大変だったりしますが、単体のリソース監視をするのであれば上記で紹介したツールで十分ですかね。

個人的にはhtopctopが好きですが、gtopもなかなか可能性を秘めているので今後、うまく活用できれば良いかなと思います。

それとスタバでhtopがカッコ良かったのも2年前の話ですね。
今風に行くならscreenコマンドで画面分割しながら、Node.JS, blessed-contribを利用して自作したリソース監視ツールを起動させつつDockerいじり倒すとか。今風がなんなのかわからないですが。

おすすめ♪ リンク♪

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Puppeteerインストール

自分用メモ

# 依存ライブラリインストール for Ubuntu 18.04
sudo apt install -y gconf-service libasound2 libatk1.0-0 libatk-bridge2.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget
# for CentOS 7
sudo yum install -y pango.x86_64 libXcomposite.x86_64 libXcursor.x86_64 libXdamage.x86_64 libXext.x86_64 libXi.x86_64 libXtst.x86_64 cups-libs.x86_64 libXScrnSaver.x86_64 libXrandr.x86_64 GConf2.x86_64 alsa-lib.x86_64 atk.x86_64 gtk3.x86_64 ipa-gothic-fonts xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi xorg-x11-utils xorg-x11-fonts-cyrillic xorg-x11-fonts-Type1 xorg-x11-fonts-misc

# [蛇足] nodebrew をよく使っているのでインストール
curl -L git.io/nodebrew | perl - setup
echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
nodebrew install-binary stable
nodebrew use stable
node -v # 正しくインストールされたか確認
npm i -g npm # npm アップデート

# インストール先を作成
mkdir foobar
cd foobar
npm init -y

# インストール
npm i puppeteer

以下のファイルを作成

example.js
const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  // CentOSの場合、Sandbox関係でエラーが発生。動かすだけが目的なので、以下のように変更
  // cf. https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md#setting-up-chrome-linux-sandbox
  // const browser = await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({path: 'example.png'});

  await browser.close();
})();
node example.js
ls
# example.png があることを確認

久々にCentOS触ったらなんかふわっとした気持ちになった。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

全部 TypeSctipt で書こう!

こんにちは。
突然ですが、TypeSctipt って便利ですよね。

私は今まで数年間 JavaScript のまま書いていました。
(TypeScript も知っていたが、なぜ変換させてまで別言語で書くの?と思っていた)

半年前、異動先の部署で使われていた TypeScript を使うことに。
導入コストがそれなりにあるし、億劫な気分でした。

ですが現在、 TypeScript にメロメロです。

TypeScript の何が良いのか

  • JavaScript の拡張言語であり、 ECMAScript の実装に準拠している
    • async/await や const/let など、 JavaScript の知識で書ける
  • JavaScript なのに型の恩恵が受けられる
    • 型の補完とか
    • 存在しないプロパティへの書き込みに対する警告とか
  • Visual Studio Code という TypeScript を正しく完璧に使うためのツールが無料

JavaScript という無法地帯に降り立った天使。それが TypeScript :angel:

TypeScript がチームの生産性を向上させた話

現在、私の開発チームはバックエンドエンジニアが私を含め3名とフロントエンドエンジニアが1名いますが、
私がフロントエンド (React.js) を書いたり、
フロントエンドエンジニアがバックエンド (Node.js) を書いたりしています。

JavaScript より型が安全で補完も効くので手が出しやすく、
コードレビューもフレームワークや思想など、
本質的な議論になる事が多いです。

少しずつそれぞれの範囲を超えて仕事できるようになってきており、
ボトルネックなタスクにリソースが集中できて効率的です。

また、もう2名も元々 Java エンジニアでしたが、
チームにジョイン後1ヶ月もかからず新機能のコンポーネントを開発してくれました。
他言語からの開発の入りやすさも言うこと無しです。

バッチ処理などのスクリプトも JavaScript の真骨頂。
もちろん TypeScript で書いています。

もう Web サービスは全部 TypeScript で書こう!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

DApps開発環境

DAppsの開発環境を設定していきます。

ツール

主に以下のものが必要になってきます

・Homebrew
Homebrewのインストールから操作まで

・Docker
Dockerインストールメモ

・Ganache
Windowsはこちらから
Macはこちらから

・Node.js

$ brew node install

・Truffle

$ brew install -g truffle//@4.1.1バージョン指定が必要な場合 

・Geth

$ brew install ethereum

ネットワークとは

Ethereumのブロックチェーンアプリを開発する際には、ネットワークに参加してブロックチェーンをしようしていく必要があります。

ブロックチェーンにおけるネットワークの仕組みを理解しておきたいと思います。

P2P(Peer to Peer)

Server-based-vs-P2P-network.jpg

今までは、サーバー型モデルと呼ばれる、サーバーがテータを保持し提供する仕組みが一般的でした。
ですがブロックチェーンではP2Pと呼ばれる、各ピア(それぞれのデバイスのこと、ノードともいう)がデータを保持し、互いにデータの提供、要求を行う自律分散型の仕組みで成り立っています。

ネットワークの種類

実際にブロックチェーンのアプリを開発する際には3種類のネットワークがあります。

メインネット

メインネットは実際の世界で使われているブロックチェーンです。
本番の環境ですので何かをやり取りする際には実際のETHが必要になります。
また、一度デプロイしてしまうとかき消すことはできません。

テストネット

メインネットにデプロイする前に開発したものがきちんとどうだするか確認するための「実験場」のようなものです。
ここでのトークンは市場価値がありません。

イーサリアムの代表的なテストネットは
・Rospoten
・Kovan
・Rinkeby

だだ、テストネットもネットに繋がっており攻撃を受けることがあり、どのテストネット一長一短あります。
Ethereum の各種テストネット比較

プライベートネット

構築者自身により構築されるネットワークのことで、個人や組織内で主に使います。

プライベートネットの構築

go-ethereumで構築する場合

Geth(Go Etherium)のプライベートネットワークの立ち上げ方法

規格のアップデートがあり仕様が変わってる部分があったなと感じたため
Gethを使ったプライベートネットの立ち上げはあまりお勧めではないです。

4.go-ethereumへの接続

$ geth attach http://localhost:8545

gethoを利用した場合

株式会社Popshoot提供する、プライベートネットをすぐに構築できるプラットフォームサービスを利用すれば簡単に構築することができます。
https://getho.io/

終わりに

ブロックチェーンにネットワークの仕組みな関してある程度理解できました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む