信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

LIST OF ARTICLES

記事一覧

  • テクログ

    ブラウザテストフレームワークの5月でした

    ブラウザテストフレームワーク、使ってますか!単体テストもいいけど、やっぱりユーザが使って実際ちゃんと動作してるの?ってのが気になりますよね。最近はjsでいろいろやることも多いし、関連するところが動かなくなったり。(jsの単体テストやれって話もありますが)で、有償無償問わず、いろいろと見てみました。結構網羅したり、試したりするだけでもそれなりにかかったので、なんとなく一覧的に。・いわゆるツールでの自動テスト系teststudioRanorexAutifyTestCompleteUnified Functional TestingROBOWAREuipathkatalon studioimacros・いわゆるブラウザテストフレームワーク(E2Eテスト用)Seleniumを直使用CodeceptionCodeceptJSNightwatch.jsWebdriverIOScrapywatirAppiumSelenideGebおよびSpockCapybaraSplinterCasperJSSST (selenium-simple-test)重要視した点としては、パッとつくれて、パッと動かせる。なんだこれ、どうやるんだ、みたいなのはなし。……ということで、有償の自動テストツール系について、可能なものは体験版を入れてちょっと動かしたりしました。「ちょっと」なのはあえてちょっとだけやって、それでもできないのならば簡単じゃない!ということでした。もちろんデモや動画をみてると、「なんかすごいことやってるし、なんでもできそう…」となりますし、実際理解すればなんでもできるのかもしれません。でも少しだけいじっただけでは全く思ったとおりに動かないんですよね。というわけでツール系はなくなり、ブラウザテストフレームワークの検証となりました。テストコード書かないといけない、というのは確かに手軽とはいえないですが、サンプルがあればあとはその改良をつづけていけばなんとかなる、という思惑です。現状のサポート具合、活発さ、書きやすさ…などからCodeceptionCodeceptJSが残り、mac,PCでのブラウザテストはクリア。実機もやりたい、ということでAppium連携をしたり…ということをやっていましたよ。実機動作は結構コツが必要だったり、iPhoneだとやりたいことがどうしてもできない部分があったり…となりましたが、それ以外は結構思ったとおりのテストができましたので、毎回確認しないといけない動作がある、とか、そういった場合には役に立つのではないでしょうか。一個小ネタでいえば、テストをAWS Lambdaに連携させて、外への影響を確認したりする、ということもやってみました。純粋なE2Eテストの範疇からは外れるかとは思いますが、やはりどうしても確認したい内容もありますので、そういうものもいかがでしょう。ちなみに最終的に残ったのはCodeceptJS+Appiumでした!(以下イメージ画像
  • テクログ

    セッションマネージャーでSSHクライアントツールとおさらばしよう!

    マスオです。最新 – AWS Systems Manager セッションマネージャーで EC2 インスタンスへのシェルアクセスを実現少し古い公式ブログ記事ですが、最近になって当社でも使い始めた機能です。一言で表現するなら 「EC2インスタンスにSSH/RDP不要でブラウザからリモート接続できる」という機能です!Tera TermやPuttyとは長い付き合いなのですが、とうとう別れの日が来たのかもしれません。導入方法は某有名サイトなど多数の記事があるので割愛しますが、この機能の画期的な点としては ❏SSH/RDP接続用クライアントツールが不要  ブラウザがあれば良い ❏接続ポートや鍵の管理が不要  IAMで一元管理できる ❏操作ログの監査がAWSで完結  S3/CloudwatchLogsで操作履歴が確認可能の三点かと思います!今まで社外からSSH接続する際にはVPN接続してーとか、そもそも秘密鍵もってなかった誰かーとかおいおい誰だよ設定ファイル変えたのーとか時々あって管理が追い付いてない感が満載でしたがこの機能を併用する事でシンプルに解決できたらなって思ってます。現状では一部サーバにしか適用していないですが、運用実績を積んで範囲を拡大していきたいと考えてます。皆様もお試し下さい。それでは、また!
  • テクログ

    Deployerでも動的にデプロイするホストを変更したい!

    ↑ってなりますよね?なるなるーホストが固定だと、deploy.phpにホストを書いて終わり、ってなるんですけど、AWSなどで今動いてるホストがコロコロ変わるとしたらdeploy.phpには固定で書けないですね。うーんこまったどうしよう。そんなときはこれ!hosts.yml〜くわしくはこちら!https://deployer.org/docs/hosts.htmlhosts.ymlにしたがってデプロイするよってしておけば、hosts.ymlを事前に生成すれば動的にできるんだ!(deploy.phpには inventory('hosts.yml');って書けば使われるよ。まあリンク先↑に書いてある。)なんだって!すごいね!はいソース の 例。pythonのほうが楽なんだけどいじりやすいようにphpにしましたですよ?雛形(SOURCE_hosts.yml)をつくっておいて、それのIPとインスタンスIDをリプレースしてるっす。わかるっすよね。雛形はじぶんでつくってね!(リンク先参照とかテストとかして)対象EC2はタグで絞り込んだりとかもしてます。これを使ってなにかあっても責任は全く取れませんなので十分に検証してね!hosts.yml生成するだけですけど。これをjenkinsに呼ばせるなら、失敗時はexit(1);とかすれば進まないのでは。ではいいかんじのDeployerライフを。<?php require 'aws_v3.phar'; use Aws\Ec2\Ec2Client as Ec2Client; use Aws\Exception\AwsException; echo 'generate_autoscale_yml START' . PHP_EOL . PHP_EOL; /**設定箇所 開始**/ //認証情報 $auth = [         "key"   => "ああああ",         "secret" => "いいいい",         "region" => "ap-northeast-1",         "version" => "2016-11-15", ]; //タグ、AutoScaleGroupの値 $AutoScaleGroup_value = 'もがもが'; //hosts.ymlの雛形となるものを読んでおく $source_hosts_yml_string = file_get_contents('./SOURCE_hosts.yml', FILE_USE_INCLUDE_PATH); //結果ファイル名 $hosts_yml_filename = './hosts.yml'; /**設定箇所 終了**/ //hosts.ymlに結果として書き出す文字列の殻 $hosts_yml_string = ''; try{     //動いている(running)、タグが該当のインスタンスを取得     $ec2client = Ec2Client::factory($auth);     $result = $ec2client->describeInstances([             'Filters' => [                     [                             'Name' => 'tag:AutoScaleGroup',                             'Values' => [$AutoScaleGroup_value],                     ],                     [                             'Name' => 'instance-state-name',                             'Values' => ['running'],                     ],             ],             'MaxResults' => 100,     ]);     //値の分解と使用     $reservations = $result['Reservations'];     foreach ($reservations as $reservation) {         $instances = $reservation['Instances'];         foreach ($instances as $instance) {             //もととなる文字のコピー             $mod_hosts_yml_string = $source_hosts_yml_string;             //置き換えに使う文字             $InstanceId = $instance['InstanceId'];             $publicip   = '';             foreach ($instance['NetworkInterfaces'] as $networkinterface) {                 $publicip = $networkinterface['Association']['PublicIp'];             }             //[INSTANCE_ID]と[PUBLIC_IP_ADDRESS]を置き換え             $mod_hosts_yml_string = str_replace('[INSTANCE_ID]', $InstanceId, $mod_hosts_yml_string);             $mod_hosts_yml_string = str_replace('[PUBLIC_IP_ADDRESS]', $publicip, $mod_hosts_yml_string);             $hosts_yml_string .= $mod_hosts_yml_string;         }     }     //書き込み     file_put_contents($hosts_yml_filename, $hosts_yml_string); } catch(AwsException $e){     var_dump($e->getMessage());     echo 'ERROR' . PHP_EOL . PHP_EOL; } echo 'generate_autoscale_yml END' . PHP_EOL . PHP_EOL;
  • テクログ

    AWS Control Tower とな!?

    マスオです。最近はAWSサービスの更新頻度についていけなくなりつつあります・・・。昨年の re:Invent 2018 にて以下のサービス(プレビュー)が発表されました。AWS Control TowerAWSを使っているとアカウントどんどん増えていって管理しきれない!みたいな状況に陥りがちだと思いますが、このサービスはそういった場合にセキュアなままで自動化や一元管理が可能となるとても便利なサービスのようです!当社もアカウントが増え続けており、管理している部署の負荷も高くなってきていますので、より少ない人的リソースで管理ができるようにするため役立ちそうです。まだ東京リージョン非対応でプレビューリリースとなっているので、まずは申込みをするところからになります。皆さんも良かったら是非お試し下さい!それではまた!
  • テクログ

    Dockerって何がいいの?

    どうも、久しぶりの投稿です。今回は初のテクログ。大した話はできないんですけども。。。ちょーど今扱ってるDockerについて良さを語りたいと思います。まず何がいいかって言うと、◆環境が一目でわかるこれに尽きると思います。今まで「サーバーに何入ってんの?」「これホントに一緒なの?」「一緒って言うたのにちゃうやん!!」っていう経験が皆さんもあったのではないでしょうか?ローカル環境と本番環境が全く同じっていう安心感ってたまんないですよね。AWSのFargateの話をすれば、、、EC2とは違い、プロビジョニングが不要ってところがアツいです。「大量アクセスきたぁー!サーバー台数増やします!」とかいらないんですよ。ある程度はスペック考えますけど、急な負荷でも自動でオートスケールをしてくれるっていう。。。いいっすね。ただ、いいことだけじゃないんです。。。デメリットもあげると、・DBキャッシュが持てない(潰して、立てる仕様だから全部リセットされちゃう)・ログも別のところに置かないといけない・IPを固定で持つことができない(これで困ることは今のところないですけど)・SSHログインできない(これつらい)SSHログインして直接ソース見たいときとかあるけど、それができない。だからログの出力が命になってきます。この環境にしてからログに残すことの大切さに今更気づきました。まぁ、でもこんなデメリットがあってもメリットの方がデカいからFargate環境を選んだんですけどね。しかも、長期休みとかでサーバーを止めておけば、その間は何と0円。EC2はサーバーを止めててもお金は発生します。でもFargateは0円。コスパいいね。みなさんも興味があれば是非触ってみて下さい。
  • テクログ

    AWS Auroraには再起動しても何しても消えないキャッシュが存在します

    AWSのAurora、使ってますか?SQLのクエリチューニング、してますか??弊社も常々WEBサイトのページ表示速度とは戦い続けていて、日々クエリチューニングをしています。そんなある日、スロークエリログにて重たいクエリを発見したので早速EXPLAINなどを使って確認しようとしたところ、1回目は激重だったのに2回目からは爆速で返ってきて「???」となりました。キャッシュだろうと思い「RESET QUERY CACHE」を打ってその後何回も実行してみましたが、結果は常に爆速。一体1回目の実施は何だったの?まさか…と思い確認したところ、Auroraではバッファプールキャッシュやページキャッシュといったキャッシュが使われこれらのキャッシュはDB再起動しても消えないしすべてのキャッシュを削除しても消えないとのことでした。つまり、初回時の速度を再現したいのであればDBインスタンスを新しく作成して実効するしかな、とのことです。詳しくはこちらの「存続できるキャッシュのウォームアップ」あたりをご覧ください。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html