DevOps

AnsibleとCapistranoの実行時はシェルの状態を確認しよう

モニターの買い替えを悩んで一生決まらないSREチームの村上です。
悩んでるうちに寒くなってきてしまったので、モニターより先に加湿器を買うことになりそうです。

さて、リンクバルでは初代Amazon Linuxで稼働しているEC2インスタンスがいくつか存在するのですが、メンテナンスサポート期限の終了が近づいていることもあり、Ubuntuへの入れ替えを進めている最中です。
「いまだに初代Amazon Linuxなんて使ってるのかよ」というツッコミは一旦置いといてください。

その入れ替えの際、bashの設定の違いにより、SSH依存のツール(AnsibleとCapistrano)の挙動も変わってしまうということがありました。
今回はbashの設定についておさらいしつつ、上記の事象の原因や解決方法について書いていこうと思います。

続きを読む

ElastiCache for Redisのバージョン間のパラメーターグループの差分を調べる

リンクバルのエンジニアの内藤 @akito_naito です。

ElastiCache for Redis 2 End Of Lifeが2023年1月13日に差し迫っています。リンクバルのサービスでも、2系のRedisを使っているサービスがあったので、アップデート作業をしていました。

その過程で、独自に定義されていたパラメータグループ、2系のデフォルトのパラメータグループ、6系のデフォルトのパラメータグループの違いを調べることがあったので、私がやった方法を紹介します。

続きを読む

DeepLens + Rekognition + Raspberry Pi で会議室を自動解錠する

2018年6月、弊社にて「OpenSesameプロジェクト」が立ち上がりました。
目的はその名の通り、「開けゴマ」です。
DeepLensを使用して会議室のドアを自動で解錠します。

今回は自動解錠システムの実装として
・Rekognition API での顔認証
・Raspbery Pi のGPIO制御
をメインにお話します。

DeepLensの基本事項や設定方法については過去記事で紹介しておりますのでそちらをご覧ください。

過去記事
AWS DeepLensを購入しました〜セットアップ編〜
AWS DeepLensを購入しました〜映像をみる、SSH接続編〜
AWS DeepLensを購入しました〜サンプルプロジェクトデプロイ編〜
AWS DeepLensを購入しました〜コミュニティプロジェクトデプロイ編〜

続きを読む

Automating security updates on AWS and pushing the output to Slack

Introduction

Hello there! My name is Adam, an aspiring DevOps engineer who joined the Infrastructure team of Linkbal this year in February. My main focuses are optimizing the AWS environments and the server middleware. Occasionally I will make something cool and useful, most likely involving AWS, which I would like to share with you.

Today, I will be detailing how to schedule a security update script to be run on an EC2 Linux instance on a time schedule, then push the output logs to a Slack channel for everyone to see.

Objectives

First, let’s consider what we want to achieve, so as to determine what the end result should be:

  1. Automatically run security updates on an EC2 Linux instance on a pre-determined schedule.
  2. Be notified of the update and see the output in a Slack channel.
  3. Be able to change the time schedule or turn on/off without having to access the instance.

The 3rd point is important as it adds a layer of convenience to the method. If it ever becomes necessary to stop the updates, we want to be able to do so quickly and easily, without having to remove what we put in place.

Pre-requisites

  • AWS account with privileges to create a CloudWatch rule and use Systems Manager.
  • EC2 Linux-based instance with AWS CLI installed.
  • IAM role attached to the EC2 instance. 
  • Permission to access the EC2 instance via SSH connection and use root credentials.
  • A Slack account with a channel for receiving the output logs and the permission to create a webhook.

Plan and script

The source code originally came from here: Slack notification via curl
The diagram was drawn using a free account in LucidChart.

[code]
#!/bin/bash

# This script runs a security update then pushes the output to Slack.

VAR1=$(sudo yum update –security -y)
IP=$(curl ifconfig.me)

function post_to_slack () {
SLACK_MESSAGE="\`\`\`$1\`\`\`"
SLACK_URL={Slack web hook} # Replace this with your own web hook, without the braces

case "$2" in
INFO)
SLACK_ICON=’:slack:’
;;
WARNING)
SLACK_ICON=’:warning:’
;;
ERROR)
SLACK_ICON=’:bangbang:’
;;
*)
SLACK_ICON=’:slack:’
;;
esac

curl -X POST –data "payload={\"text\": \"${SLACK_ICON} ${SLACK_MESSAGE}\"}" ${SLACK_URL}
}
post_to_slack "Result of security update for $IP: $VAR1" "INFO"
exit 0
[/code]

Procedure

  1. Create a Slack web hook for the channel you want to receive the log output in. Paste the web hook into the script as the value for SLACK_URL (without the {} braces).
  2. Upload script to the instance (take a note of the path). This can be done from the command line as such:
    $ scp -i /path/to/key.pem ec2-user@{IPv4 DNS}:path/to/file
    Or you can SSH connect to the instance, make a new file and paste the code in there:
    $ ssh -i /path/to/key.pem ec2-user@{IPv4 DNS}
    $ vi /path/to/file/update_security.sh
    It doesn’t matter were the file goes, so long as you know where it is.
    Be sure to change the permissions on the script so that it can be executed.
    $ chmod 775 /path/to/file/update_security.sh
    Install the AWS SSM agent: (installed by default on AWS Linux 1 AMIs since 2017.9 and on all AWS Linux 2 AMIs)[Manually install SSM agent on Amazon EC2 Linux instances]
    Add the policy “AmazonEC2RoleforSSM” policy to the role being use by the EC2 instance.
  3. Go to CloudWatch, select “Rule” on the left toolbar and then “Create rule”. Set the time expression by either a fixed rate or a cron expression. Note that the time will be in UTC, so depending on your timezone you will need to adjust the hour and possible day values. As an example, to update at 2am UTC Monday-Friday, the expression would be:
    0 2 ? * MON-FRI *
    For help with cron expressions in AWS, please see: AWS CloudWatch – How to schedule events
    Select “SSM Run Command”.
    Select the document “AWS-RunShellScript (Linux)”
    Target key = InstanceIds (can choose a different target, if you prefer)
    Target values = {Instance ID} i.e. i-a1b2c3d4e5
    Click on the “Configure parameters” drop down.
    Commands = ./update_security.sh
    WorkingDirectory = /path/to/file/
    ExecutionTimeout = 100
    Select “Create a new role for this specific resource”
    Click on “Configure details”. Give it a name and a description.
  4. The CloudWatch Rule uses AWS Systems Manager to call the SSM Agent which runs the script.  The script will run the update, then pass the output to a post function which uses the Slack web hook to post the output in your channel.
    Even if there are no updates due, the message will still be sent.
  5. Success! You can customize the name and image of the web hook in the Slack settings menu.

 

Conclusion

We have now configured for security updates to run on the AWS EC2 Linux instance on a specific time schedule, with the result of the update being sent to a channel in Slack. The script can be turned on/off easily from the AWS console (or by the AWS CLI) and we can change the time schedule there as well.
Let us now consider the advantages and disadvantages of this method.

Advantages

  • Quick and simple to set up.
  • The script is reusable; can be used on most if not all Linux instances on AWS. Only the Slack web hook would have to be changed if a different channel was required, otherwise no need to edit the script.
  • Only a basic understanding of AWS is required.
  • Virtually zero cost.

Disadvantages

  • CloudWatch rule must be stopped manually. Could set up a trigger with SMS and Lambda to stop the rule without the need for human intervention.
  • Only works for Linux instances. Windows would require something different.
  • Root privileges are required to set up (possibly avoidable with AWS Systems Manager).
  • Would be easier to understand if more details concerning the instance were put into the script, such as the name tag. (Can use ec2-metadata to obtain a lot of this information, but tags are not included in this list. Could use AWS CLI to get the instance name tag.)

Overall we have achieved what we set out to do. There are ways we could improve the script, but for now this is more than suitable.

I hope you have enjoyed this post, it’s a simple start with many more things to come. See you next time!

References

  1. Source code: http://blog.pragbits.com/it/2015/02/09/slack-notifications-via-curl/
  2. LucidChart: https://www.lucidchart.com/
  3. AWS CloudWatch – How to schedule events: https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html
  4. AWS EC2 – Manually install SSM Agent on AWS EC2 Linux instance: https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html
  5. Manually install SSM agent on Amazon EC2 Linux instances : https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html

 

 

 

 

 

 

 

 

GitLabの導入(Backlog + GitHub からの移行)

いま、社内に GitLab を導入中です。数ヶ月かけて、これまで利用していた Backlog と GitHub を、GitLab に置きかえていく予定です。

Backlog は課金額がユーザ数に依存しません。そこで、いろいろな人が関わる課題管理には Backlog を利用しています。過去の履歴を見ると、2013年から 5年以上もお世話になっています。現在のアクティブユーザー数は120名ほど。

一方 Backlog の Gitリポジトリ機能はそれほど魅力的ではないため、コード管理には GitHub を利用しています。しかし GitHub はユーザ毎にお金がかかるため、コードを書く人に限定して使っています。現在のアクティブユーザー数は50名ほど。

開発の流れ

当社の開発の流れは、だいたい次のようになっています。

  1. 誰かが「○○をやりたい」と提案する。誰が何を提案してもいい。要点をまとめて Backlog に proposal(提案)として登録する。
  2. やるか、やらないか、優先度はどうするか、を毎朝のミーティングで決める。
  3. やることになった案件は planning(企画)フェーズに移行し、ディレクター、デザイナー、エンジニアなど案件毎に適切な人が仕様を決める。
  4. planningフェーズの仕様をレビューして問題がなければ、dev フェーズに移行させる。課題の優先度は毎朝の会議で決める。
  5. 優先度高の課題の中から好きなものを、手が空いたエンジニアが自分で取っていく。
  6. 開発が終わったら、提案者やディレクターがテストする。問題がなければリリース待ちとなる。
  7. リリースする。「街コンジャパン」の場合、少ない日で 1件、多い日で 10件くらいのリリースをする。ただし、売上が一番多いのが土日祝であるため、休みの前日のリリースはなるべく避ける。
    続きを読む

AWS re:Invent 2018 参加レポート : 海外カンファレンスについて

リンクバル技術部の川畑です。AWS re:Invent 2018の全日程が終了しました。。
せっかく海外カンファレンスに参加したので、企業がエンジニアを海外カンファレンスに参加させる目的とその効果ついて考えてみましたので、こちらに纏めさせて頂きます。
ちなみに私は海外カンファレンスはAWS re:Inventしか参加したことないので、AWS re:Invent寄りの内容になることをご了承ください。

続きを読む

AWS re:Invent 2018 参加レポート : 4日目

リンクバル技術部の川畑です。AWS re:Invent 2018に参加するためラスベガスに来ています。本日もKeynoteでLambdaでのRubyサポート、そしてCOBOLも使えるようになるなど衝撃的な新サービスの発表がありました。
特にサーバーレスについては、Lambdaの前にALBを配置することが可能なので、WAFを設定できるようになり、DBはDynamoDBがトランザクションをサポート開始し、オンデマンドの従量課金体系に変わったので、これからはセキュリティやデータベースの制約でLambdaにできなかったシステム開発が可能となり、Lambdaを使ったサーバーレス化が加速するのではないかと思われます。
本日はそのLambdaのセキュリティ観点を学ぶために「Securing Serverless Applications and AWS Lambda」というワークショップを受けてきたので、その内容を簡単に共有させて頂きます。

続きを読む

AWS re:Invent 2018 参加レポート : 3日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。Amazon Web ServicesのCEO Andy Jassy氏による Keynote に参加してきました。毎年新たなサービスが発表されるのが恒例となっているようです。朝8時に開始にもかかわらず、朝7時に到着した時点ではすでに300メートルの10列ぐらいの行列ができていました。それでも何とか中にはスムーズに入ることができました。この辺りの誘導は手慣れたものだなと思いました。

会場の様子はこんな感じです。

本日のKeynoteでは以下のサービスが発表されました。

続きを読む

AWS re:Invent 2018 参加レポート : 2日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。
渡米するのは今回が初めてで、すべての食事はデカくて肉ばかり、という印象を持っていましたが、AWS re:Invent で提供される食事はベジタリアンの方を考慮してか、野菜が多く提供されている印象です。ライスは食べてませんが、日本にいるより野菜と果物を多く摂取している感じです。
2日目の今日は以下の Session に参加してきました。

  • SEC322-R – [REPEAT] Using AWS Lambda as a Security Team
  • DEV315-S – Building SRE from Scratch at Coinbase during Hypergrowth
  • CON301-R1 – [REPEAT 1] Mastering Kubernetes on AWS
  • DAT401 – Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB

本日はこの中の、Uging AWS Lambda as a Secutiry Team のセッションの内容についてご紹介させて頂きます。

続きを読む

AWS re:Invent 2018 参加レポート : 1日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。本日は以下の Session に参加してきました。

  • Scaling Push Messaging for Millions of Netflix Devices
  • Unleash Team Productivity with Real-Time Operations
  • [REPEAT] Creating and Tuning Models with Amazon SageMaker
  • Keep Your IoT Devices Secure
  • Monday Night Live

Netflixのプッシュメッセージのアーキテクチャ、PagerDutyのDevSecOpsの事例などが聞けていろいろと参考になりました。本日は Key Note の1つである Monday Night Live について書かせて頂きます。

続きを読む