OSS

2017年4月21日 (金)

VSCodeでElectronアプリをデバッグするときのlaunch.json

とあるイベントでElectronが面白そうと思って、ちょっと触ってみたのですが、VSCodeでのデバッグ設定でハマったのでメモ。

<前提環境>

・Windows 10 Creator Update
・nodistでnpm 6.9.2
・VSCode 1.11.2
・Electron 1.6.5(「npm install electron -g」でインストール)
とりあえず、サンプルでよくあるファイル(index.html, main.js, package.json)作って、.vscodeフォルダにlaunch.json作ってデバック実行してみると、こんな感じでエラーが( ;∀;)
001
ざっと検索してみると、「Windowsだと'.bin/electron'じゃなくて'.bin/electron.cmd'を呼び出さないといけない」とあるけど、元々VSCodeに登録されているElectron用テンプレートにはちゃんと指定してある・・・。
002
よくよく考えると、'${workspaceRoot}'ってVSCodeが開いているフォルダになるので、その配下にelectron.cmdなんてあるわけない!
でも、パスを直接書くのは嫌なので、何か参照できるものはないかと思ってたら、OS環境変数に'NODIST_PREFIX'があるのを発見(ちなみに、x64環境だと'C:\Program Files (x86)\Nodist'になります)。
Nodistの配下に'node_modules\.bin'フォルダもあったので、'${env.NODIST_PREFIX}/node_modules/.bin/electron.cmd'に変えてみたものの、これでもNG。
'electron.cmd'を探してみると、'C:\Program Files (x86)\Nodist\bin'に居た!!
ということで、windows用のruntimeExecutableの指定は'${env.NODIST_PREFIX}/bin/electron.cmd'で無事落ち着きました。

2016年8月23日 (火)

PXEブート環境を作成する

今回は備忘録的に超概略レベルで作成してます。

Hyper-V環境で新しい仮想マシンにISOファイルを指定するのがそろそろ面倒になってきたので、PXEブート環境を作成してみました。
最近はLinuxも使ってるので、サーバはCentOS7とWindowsです。
→既存のDHCPサーバ(Windows)とは別にPXEサーバを作成します。
 ※DHCPサーバの設定が変更できることが前提

<PXEサーバ(CentOS)側>
01.CentOS7をインストールする。
02.yum install httpd
03.firewall-cmd -add-service=http --permanent
04.firewall-cmd --reload
05.「/var/www/html/index.html」としてテストページを作成して、他のマシンから「http://[サーバ名]」でアクセスできることを確認
06.yum install syslinux xinetd tftp-server
07.mkdir /var/lib/tftpboot/pxelinux.cfg
08.cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot
09.cp /usr/share/syslinux/menu.c32 /var/lib/tftpboot
10.vi /etc/xinetd.d/tftp
 「disable = yes」→「disable = no」
11.start xinetd
12.enable xinetd
13.mkdir /var/lib/tftpboot/centos7
14.cp /run/media/[ログインユーザ名]/CentOS 7 x86_64/images/pxeboot/initrd.img /var/lib/tftpboot/centos7
 ※Hyper-Vの仮想マシンでCentOS7のISOイメージをマウントすると「/run/media/[ログインユーザ名]/CentOS 7 x86_64」にマウントされる
15.cp /run/media/[ログインユーザ名]/CentOS 7 x86_64/images/pxeboot/vmlinuz /var/lib/tftpboot/centos7
16.vi /var/lib/tftpboot/pxelinux.cfg/default
  timeout 300
  default menu.c32
  
  menu title ***** PXE Boot Menu *****
  label 1
    menu label ^1. local boot
    localboot
    
  label 2
    menu label ^2. Install CentOS7
    kernel centos7/vmlinuz
    append initrd=centos7/initrd.img inst.repo=http://[サーバ名]/pxeboot/centos7 devfs=nomount

17.mkdir /var/www/html/pxeboot/centos7
18.cp -R /run/media/[ログインユーザ名]/CentOS 7 x86_64/ /var/www/html/pxeboot/centos7

<DHCPサーバ(Windows)側>
1.DHCP管理画面の「サーバー オプション」として
 ・「066 ブート サーバー ホスト名」に'[PXEサーバ名]'
 ・「067 ブート ファイル名」に'/pxelinux.0
 を設定

DHCPサーバの設定変更ができないときは、DnsmasqでProxy DHCPを使えば対応できるらしいのですが、実機検証できたらまた書きます。

あと、Hyper-VでCentOSをPXEブートするときは、第1世代の仮想マシンを使用する必要があります。
→ISOイメージを直接マウントするときは第2世代でセキュアブートをOFFにすればインストールできますが、PXEブートでは起動イメージがロードできずにエラーになります。

2016年6月23日 (木)

vstsAgentとGradleをAnsibleで入れてみる

いつの間にか、VSTS/TFSのLinux/OSX用ビルドエージェントの名前が「vsoAgent」から「vstsAgent」に変わってたので、改めて入れてみようと思い立ち、やるなら巷で噂のAnsibleも使ってみようとしました。

前回のGitBucketに続き、環境はCentOS7、Ansible:2.0.2.0になります。
古いAnsibleのバージョンでのサンプルが結構あったので、新しいバージョンでどう変わったかも確認してみました。
とりあえず作ってみたレベルなので、vstsAgentの設定変更やRoles分けはできてません。

<hosts>
[buildagent-servers]
192.168.xxx.xxx

[buildagent-servers:vars]
ansible_ssh_user=ansiuser
ansible_ssh_pass=xxxxxxxx
ansible_sudo_pass=xxxxxxxx


<playbook>
---
- hosts: buildagent-servers
  remote_user: ansiuser
  vars:
   download_agent_archive: vsts-agent-rhel.7.2-x64-2.101.1.tar.gz
   base_dir: "{{ ansible_env.HOME }}/buildagent"

  tasks:
  - name: Create base directory
    file:
    args:
     path: "{{ base_dir }}"
     state: directory
     mode: 0755

  - name: Create download directory
    file:
    args:
     path: "{{ base_dir }}/download"
     state: directory
     mode: 0755

  - name: Download vstsAgent
    get_url:
    args:
     url: "http://github.com/Microsoft/vsts-agent/releases/download/v2.101.1/{{ download_agent_archive }}"
     dest: "{{ base_dir }}/download"
     force: no

  - name: Deployment vstsAgent
    unarchive:
    args:
     copy: no
     src: "{{ base_dir }}/download/{{ download_agent_archive }}"
     dest: "{{ base_dir }}"
     creates: "{{ base_dir }}/run.sh"

  - name: Download gradle archive
    get_url:
    args:
     url: "https://services.gradle.org/distributions/gradle-2.13-bin.zip"
     dest: /tmp
     force: no

  - name: Deployment gradle
    unarchive:
    args:
     copy: no
     src: /tmp/gradle-2.13-bin.zip
     dest: /opt
     creates: /opt/gradle-2.13
    become: yes

  - name: Create gradle symbolic link
    file:
    args:
     src: /opt/gradle-2.13
     path: /opt/gradle
     state: link
    become: yes

  - name: export GRADLE_HOME
    lineinfile:
    args:
     dest: /etc/profile.d/gradle.sh
     line: export GRADLE_HOME=/opt/gradle
     create: yes
    become: yes

  - name: export gradle path
    lineinfile:
    args:
     dest: /etc/profile.d/gradle.sh
     line: export PATH=$PATH:$GRADLE_HOME/bin
    become: yes


<補足>
・相手先ホストでssh接続を設定する必要がある
・相手先ホストが複数の場合、ssh接続ユーザ/rootのパスワードを揃えた方が楽。(まとめて指定できる)
・OS環境変数は「ansible_env:~」で参照可能
・「Create ~ directory」は、pathに指定されたディレクトリが存在したらスキップ
・get_urlでforce: noの場合、ダウンロード対象が存在したらスキップ
・unarchiveでCopy: noとすることで、相手先ホスト内のファイルを解凍対象にできる
 たしか、古いバージョンだとAnsibleのホストサーバから強制ダウンロードだったはず
・unarchiveでcreates:~に指定したファイルが存在したらスキップ
 解凍後のファイルを指定すれば、再解凍せずにすむ
・sudo実行時は「become: yes」 ← 昔のバージョンだと「sudo: yes」
・gradleの実行パスは、バージョン切り替えできるようにsymbolic linkを使ってみた
・環境変数の変更は、CentOSだと「etc/profile.d」ディレクトリにあるシェルスクリプトを自動で取り込んでくれるので、今回は「gradle.sh」を個別作成した

Ansibleを全然使ったことがなかったので四苦八苦しましたが、一度作成したら離れられませんね。あとは接続先ホストでAnsibleが使えるようになるまでの初期設定(ホスト名/ネットワーク設定/ssh設定など)をどうにかできないかなと。それとWindows対応か・・・。
あ、yumを使うパターンがないw

ちなみに、相手先ホストはHyper-V仮想マシン、Playbookは前回書いたGitBucketでバージョン管理させてるので、「動かしてみてダメだったら戻してしまえ」ができるのは大きいです。

2016年6月 4日 (土)

CentOS7にGitbucketをインストール

結構いろいろ悩んだのでメモとして。

<対象バージョン>
CentOS:7
Apache httpd:2.4.6
Java:OpenJDK 1.8
GitBucket:4.1

<手順>
毎回sudo打ちたくないので、suでrootで実行。
※自ホストを「server1.local」にしてますが、実際に作成したホスト名に変えてくださいね。

○アプリのインストール
# yum -y install java-1.8.0-openjdk java-1.8.0-openjdk-devel
# yum -y install tomcat
# yum -y install httpd
# cd /var/lib/tomcat/webapps
# wget https://github.com/takezoe/gitbucket/releases/download/4.1/gitbucket.war

○サービス化/起動
# systemctl enable httpd
# systemctl start httpd
# systemctl enable tomcat
# systemctl start tomcat
ここまでで、自ホスト内で「http://server1.local:8080/gitbucket」でアクセスできるが、他ホストからは接続できない。

○ポート変更
「http://server1.local/gitbucket」でアクセスできるように変更します。
# vi /etc/tomcat/server.xml
・ServerNameを自ホストに変更します。
 ServerName server1.local:80
・httpdの8080ポートを閉じます。
 以下の部分を「<!-- -->」でコメントアウト。
 <Connector port="8080" protocol="HTTP/1.1"
            connectionTimeout="20000"
            redirectPort="8443" />

#vi /etc/httpd/conf.d/gitbucket.conf
・AJPを使ったProxyPassを設定します。
 ProxyPass /gitbucket ajp://server1.local:8009/gitbucket

# systemctl restart httpd
ここまでで、自ホスト内で「http://server1.local/gitbucket」でアクセスできるが、他ホストからは接続できない。

○Firewallの設定変更
他ホストから接続できるようにhttpポートを通すようにします。
# firewall-cmd --add-service=http --permanent
# firewall-cmd --reload
ここまで変更すると、他ホストからも「http://server1.local/gitbucket」でアクセス可能。

<補足>
○デフォルトでAJPのConnectorは有効になっています。
 (<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />)
○ネットで検索すると、「LoadModule proxy_module modules/mod_proxy.so」とかをhttpd.confに追加する手順がよく出てくるのですが、デフォルトだとhttpd.confに「Include conf.modules.d/*.conf」があって、「conf.modules.d/00-proxy.conf」に「LoadModule proxy_module modules/mod_proxy.so」「LoadModule proxy_ajp_module modules/mod_proxy_ajp.so」があるので追加しなくても大丈夫。
○ProxyPassの設定で、VirtualHostディレクティブを使うパターンとLocationディレクティブを使うパターンがよく出てくるのですが、バーチャルホストしないのであればVirtualHostは指定したくないですし、Locationディレクティブは公式ドキュメントを見ると「<Location>ディレクティブは ファイルシステム外のコンテンツにディレクティブを適用するときに 使用してください。」とあるのでこれも指定したくないということで、今回は両方とも使わず、直接ProxyPassディレクティブを使ってます。

無料ブログはココログ