投稿

オンプレサーバでGitlabを構築したときの記録

イメージ
サーバーが一台空いたので、UbuntuサーバーをインストールしてGitlabを立ち上げた。Githubなどの外部サービスにアップロードできない環境はそれなりに存在してるはずなので、こうして展開する機会は今後もありそう。 Ubuntu Serverのインストール直後から、Gitlabをセットアップし最初のリポジトリを作るまでの手順を残しておく。 [バージョン情報] Ubuntu Server 18.04.1 LTS GitLab Community Edition 11.8.1 Windows10(クライアント) git 2.21.0.windows.1(クライアント) ちなみに公式のインストール手順はこちら(https://about.gitlab.com/install/) Ubuntuのインストール 公式サイトから落としたイメージでUbuntu Serverをセットアップする。立ち上がったらネットワークの設定を行い、Open SSHサーバをインストールする。 $sudo apt-get install curl openssh-server ca-certificates Postfixをインストール メールサーバのPostfixをインストールする。今回はメール機能は使わなかったが、公式のinstallationに書いてあるのでとりあえず入れた。インストール時のGeneral TypeではLocal Onlyを選んだ。 なお後から試したが、インストール後の設定で外部のメールサーバを利用することもできたので、その場合は特にPostfixをインストールする必要はない。 $sudo apt-get install postfix Gitlabのインストール Gitlabの公式リポジトリを登録し、インストールを実行する。 $curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash $sudo apt install gitlab-ce Gitlab設定の変更 インストール後、Gitlabの設定ファイル(/etc/gitlab/gitlab.rb)を開いて修正する。設定は沢山あ...

Git参加者の基本的なフローと操作

イメージ
開発でGitを利用するにあたって、参加者が行う基本的な操作のまとめ。それぞれの運用で違いはあると思うが、だいたいこんな感じ。一応環境はWindowsで、PowershellでのCUI操作を想定している。 Git環境の準備 Git for windowsをインストールしたら、以下の環境設定を行う。 ユーザー情報の設定 登録ユーザーとメールアドレスを設定。ユーザIDとパスワードは初回アクセス時に聞かれる。 >git config --global user.name "〇〇〇〇" >git config --global user.email "example@mail.com" ページャとエディタの設定 デフォルトのページャは日本語が文字化けするので変更する。"cat"はPowershellでは"Get-Content"のエイリアス。lessのように行を読み進める形にはならないが、Powershellだと長いテキストもスクロールして読めるので問題ない。 >git config --global core.pager "cat" コマンドから起動されるエディタも変更する。vimの操作はWindowsユーザには馴染みがない。慣れておいて損もないが、インストールしたままだとやはり日本語が化ける。こだわりが無ければメモ帳にしてしまえ。 >git config --global core.editor "notepad" 2019/08/05追記:git statusなどで日本語ファイル名が文字化けするのを避ける。 >git config --global core.quotepath false 開発フォルダのセットアップ 開発プロジェクトの作業フォルダを作ったら、リモートリポジトリをクローンする。 >git clone http://gitlab.example.com/project_path.git クローン後、リソースファイル等のgit対象外のファイルを別途コピーする。他の人の開発フォルダの中身をコピーして、同じ名前のファイルはすべて「上書きしない」を選ぶのが手っ取り早い...

図で見るGitの各操作

イメージ
Gitの各操作で何が起きるのかが掴みづらいので、いちど自分の認識を図にしてみる。画像が多いので注意。 そもそもGitが初見で混乱するのは  ・リモートとローカルそれぞれのリポジトリ  ・ブランチという派生バージョンの切り替え  ・ステージングエリア(インデックス)という一時領域 これらの存在が一度に出てくるせいだと思うので、その辺を中心に書き起こした。 各操作のイメージ リモートリポジトリのクローン(git clone ~) リモートリポジトリ全体(ブランチも含む)をローカルに複製。ファイルも生成される。 派生ブランチを切る(git branch BRANCH_NAME) 元のブランチと親子関係のある派生ブランチが生成される。 ファイルの編集 ユーザーがファイルを編集する。この時点ではまだリポジトリの情報は変化しない。 更新の追加(git add ~) ファイルの更新や削除の情報をステージングエリアへ登録する。 更新の追加の取消(git reset) ステージングエリアの情報を削除する。ファイル実体が戻るわけではない。 コミット(git commit) ステージングエリアの変更を確定し、特定のブランチへ登録する。ステージングエリアに追加されていない変更は含まれない。 ブランチの切り替え(git checkout BLANCH_NAME) ブランチを切り替えると、切替先のブランチに一致するようにファイル実体が置き換えられる。未コミットの修正(ステージングエリア含む)はそのまま引き継がれる。 置き換え対象のファイルと未コミットのファイルが被った場合はエラーになる。ユーザーの編集が上書きされて消えないようにだと思われる。 ファイルを元に戻す(git checkout BLANCH_NAME FILE_NAME) ファイル実体を特定のブランチの状態に戻す。ブランチ名を省くとステージングエリアになる。 プッシュ(git push origin BRANCH_NAME) ローカルリポジトリのブランチをリモートリポジトリにアップロードする。 マージ(git merge ~) ブランチを統合する。 リモートの更新を同期(git ...

Ubuntu+ASP.NET CoreでWebサービス(3)/Nginxから転送

イメージ
前回 [バージョン情報] Ubuntu Server 18.04.1 LTS .NET Core 2.1 Nginx 1.14.0 Windows10(クライアント) Visual Studio 2017 Community(開発環境) みんな知ってるWebシステムの三層構造。前回はkestrelのホストしているURLに直接リクエストを投げたが、区分としてはASPはアプリケーションサーバだろう。なのでその前段階にWebサーバを構築する。 Webサーバには最近のスタンダードらしいNginxを使ってみる。MSの公式でもNginxを使用する方法が書いてある( リンク )ので、よくある構成かと思われる。 Nginxのインストール Ubuntuの公式リポジトリに含まれているので、apt installだけでダウンロードからインストールまでできてしまう。 $sudo apt install nginx インストールしたらnginxサービスを起動する。 $sudo systemctl start nginx コンソールには何も出てこないが、curlやブラウザでアクセスすると「Welcome to nginx!」のHTMLページが返ってくる。 補足:systemctl start nginx の代わりに service nginx start でも起動する。後者はサービスのみに対応したスクリプトコマンドで、実行結果は基本的に同じようだ。ただsystemctlの方が汎用的みたいなのでこちらに慣れておく。 リバースプロキシの設定 Nginxの既定のサイトの構成ファイル[/etc/nginx/sites-available/default]に転送設定を加える。 location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. try_files $uri $uri/ =404; } location /api/ { proxy_pass http://localhost:5000; ...

Ubuntu+ASP.NET CoreでWebサービス(2)/ASP.Net Coreを動かす

イメージ
前回 今回はASP.NET Coreのプロジェクトを作ってUbuntuで動かすまでのメモ。 [バージョン情報] Ubuntu Server 18.04.1 LTS .NET Core 2.1 Windows10(クライアント) Visual Studio 2017 Community(開発環境) プロジェクトの作成 Visual StudioでASP.NET Coreのプロジェクトを新規作成する。 テンプレートにはAPIを選択。Webアプリケーションとかを選ぶとビュー生成用のコードなどが配備される。でもサーバサイドはAPIの提供に専念する方がきれいだと思う。(.NET FrameworkのWeb APIテンプレートはViewに相当する参照が沢山含まれれて不便だった) 新規プロジェクトにはAPIのサンプルコードとしてValuesController.csが含まれている。 namespace WebApplication1.Controllers { [Route("api/[controller]")] [ApiController] public class ValuesController : ControllerBase { // GET api/values [HttpGet] public ActionResult<IEnumerable<string>> Get() { return new string[] { "value1", "value2" }; } ~省略~ } } この〇〇ControllerクラスがAPIの処理を記述する部分になる。ざっくり言うと、クラスやメソッドにルーティングの属性を付けることで、リクエストに対して呼び出されるメソッドを指定している。この場合"http://xxxx/api/Values/"にGETリクエストすると、サーバではGetメソッドが呼ばれて戻り値の["value1", "value2"...

Ubuntu+ASP.NET CoreでWebサービス(1)/.Net Coreを動かす

イメージ
表題の通り。ASP.NETがLinux上で動くと聞いて、Windows系のプログラマでも手が出そうだと思い試してみることに。 まずはASPの前に.NET Coreが動く環境を作るところまで。 [バージョン情報] Ubuntu Server 18.04.1 LTS .NET Core 2.1 Windows10(クライアント) Visual Studio 2017 Community(開発環境) Ubuntu Serverの準備 最終的にはVPS等を使うつもりだけど、まずはVirtualBox上で構築してみる。 インストールメディアのisoイメージを公式ページ( https://www.ubuntu.com/ )からダウンロード。VirtualBoxで新規VMを作り、光学ドライブにisoファイルをマウントしてインストール。なお18.04にはまだ日本語は無いそうで。操作はともかくテキストファイルの中身も読めないのは不都合がありそう。 インストールしたらネットワークの設定だけする。VMに割り当てるのは、外部通信用のNATと、ホストからアクセスする用のホストオンリーアダプターの2つ。 NAT側は自動割り当て、ホストオンリーアダプター側はホストマシンの[VirtualBox Host-Only Network]アダプタと同じネットワークになるように固定IPアドレスを割り振る。ちなみにUbuntu 18.04のネットワークの設定ファイルは[/etc/network/interfaces]ではなく[/etc/netplan/50-cloud-init.yaml]。 # This file is generated from information provided by # the datasource. Changes to it will not persist across an instance. # To disable cloud-init's network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # networ...