以前にこういう記事を書きました。
しかし、PostgreSQLではセグメンテーション違反は起きなくなったのですが、Redisに接続する箇所で起きるようになったので、抜本的な問題解決にはなりませんでした。
ということで、私の中でMacでRailsアプリ開発は厳しい、という結論に。
しょうがないので、Rubyの実行環境自体をMacからDockerにしていこうと思います。
現場からは以上です。
pgのバージョンを0.21.0にしたらセグメンテーション違反が起きなくなった
少し前に、Railsを起動するとセグメンテーション違反が起きたが、原因がわかった的な記事を書いてた。
これで落ち着いたかと思いきや、全然落ち着いておらず、またもやセグメンテーション違反が起きた。シングルプロセスでアクセスする場合は落ち着いていた感じだったのだが、Resque等のバックグラウンド処理用のワーカープロセスを起動すると、落ちまくった。heroku localを実行すると、ほぼセグメンテーション違反が起きた。
周囲に聞いてみても、落ちないですけどねーと言われるので、そのプロジェクトのGemfileを見てみたら、pgのバージョンが0.21.0だった。今は1.2.2が最新である。当初は「いやいや、もう1系出てるのに未だに0.21.0て…。アップグレードしないとダメでしょ」と思っていたのだが、試しにダウングレードしてからheroku localを実行したところ、セグメンテーション違反が全く起きない…。
一旦、ダウングレードして様子見しようかと思う。 とはいえ、これでいいとは思っていないので、時々アップグレードしながら探ってみようかと思う。
Rails 6のCredentials方式をRails 5.2にバックポートした
私が担当している製品の機密情報の管理は、Rails 5.1で導入されたEncrypted Secrets(secrets.yml.encを使う方式)を使っていて、5.2になって導入されたCredentials方式の導入は見送っていました。
理由は、5.2のCredentials方式だと、各環境毎の設定が行えなかったからです。そのため、5.2のリリース後にはCredentialsを複数の環境で扱えるようにするためのgemがいくつか出てきました。しかし、そこまでしてCredentialsに移行しても、ある意味レールから外れたカスタマイズをすることになりますし、Encrypted Secretsが非推奨になったわけではなかったので、Encrypted Secretsを使い続けていました。
現在もまだRails 5.2系を使っているのですが、これを6系にバージョンアップするために引っかかりそうなところを調査していたところ、Rails 6からはCredentials方式を後方互換性を保ったまま、各環境で使えるようになったという記事をRails 6エンジニア養成読本で読みました。
これを使えるようにしたいのですが、いきなり6にアップグレードすることは難しいです。
そこで、まずこの機能を先に取り込めるかどうかを検証しようと思いました。
バックポート用のコードを発見
調べ始めてちょっとしたら、gistで希望通りのコードと思われるものが公開されていました。
Backport Rails 6 per-environment credentials · GitHub
これを検証したところ、Rails 6のCredentialsと同様に各環境用のcredentials.yml.encとmaster.keyが作られました。
導入
導入に関しては、上記のgistを参考にしてください。
各環境のCredentialsを作成する
Rails 6のCredentialsの作成と同様の手順で行えます。下記のコマンドを実行すると、config/credentials/staging.yml.encとconfig/credentials/staging.keyが生成された後、VSCodeでstaging用のCredentialsの設定ファイルが開きます。
env EDITOR="code --wait" bin/rails credentials:edit --environment=staging
適当に入力後に保存して、そのファイルのタブを閉じると、設定完了です。簡単。
各環境のCredentialsを見る
Encrypted Secretsの頃は設定項目を見るだけのコマンドがなかったので、わざわざ編集モードで開く必要があったのですが（変更なしでも変更と見なされるのでgitで戻す必要があった）、Credentialsならば、閲覧用のコマンドがあります。便利！
bin/rails credentials:show --environment=staging
Credentialsに移行するために行なった作業
ざっくりとした手順は、以下の通りです。
secrets.yml.keyをコピーしてmaster.keyを作る。secrets.yml.encから各環境用に値をコピーする。Rails.application.secretsをRails.application.credentialsに一斉置換する。config/environments/production.rbをはじめとする全ての環境でEncrypted Secretsを使う設定を削除、RAILS_MASTER_KEYを必須とする設定を行う- 開発環境で動作検証を行う
- stagingの環境変数
RAILS_MASTER_KEYの値をconfig/credentials/staging.keyの値に変更する - stagingにデプロイして動作検証を行う
- 問題ないことを確認後、
secrets.yml,secrets.yml.enc,secrets.yml.keyを削除する。
master.keyを作る
master.keyには、本番環境で設定されている環境変数RAILS_MASTER_KEYと同じ値を設定します。これはsecrets.yml.keyと同様のはずですので、コピーしてしまいます。
cp config/secrets.yml.key config/master.key
また、忘れずに.gitignoreにmaster.keyを追加しておきましょう。
/config/master.key
各環境用に機密情報をコピーする
以下のコマンドでEncrypted Secretsを表示します。
env EDITOR="code --wait" bin/rails secrets:edit
Encrypted Secretsの頃は、yamlのrootに環境名を設定する必要がありました。
production: aws: access_key: foo access_secret_key: bar staging: aws: access_key: foo_staging access_secret_key: bar_staging
これを、各環境のCredentialsにコピーしていきます。
production環境
まず、production環境です。以下のコマンドを実行すると、config/credentials.yml.encが生成され、編集モードで開きます。
env EDITOR="code --wait" bin/rails credentials:edit
以下のように設定し、保存します。
aws: access_key: foo access_secret_key: bar
staging環境
次に、staging環境です。以下のコマンドを実行すると、config/credentials/staging.yml.encとconfig.credentials/staging.keyが生成され、編集モードで開きます。
env EDITOR="code --wait" bin/rails credentials:edit --environment=staging
以下のように設定し、保存します。
aws: access_key: foo_staging access_secret_key: bar_staging
こんな感じで環境の数だけ作っていきます。
development, test環境
secrets.ymlも削除したいため、development, test用のCredentialsも作成しました。
secrets.ymlに設定していた内容をコピーします。
env EDITOR="code --wait" bin/rails credentials:edit --environment=development
test環境も同様に行いました。
機密情報の参照先を一斉置換する
Credentialsは指定方法がRails.application.credentialsなので、Rails.application.secretsをRails.application.credentialsに一斉置換します。
各環境でEncryped Secretsを使う設定を削除
config/environments/production.rbなど、Encrypted Secretsを使っていた環境で、以下の行を削除します。
# Attempt to read encrypted secrets from `config/secrets.yml.enc`. # Requires an encryption key in `ENV["RAILS_MASTER_KEY"]` or # `config/secrets.yml.key`. config.read_encrypted_secrets = true
そして、環境変数RAILS_MASTER_KEY、又はmaster.keyに該当するものを必須とする設定を行います。
# Ensures that a master key has been made available in either ENV["RAILS_MASTER_KEY"] # or in config/master.key. This key is used to decrypt credentials (and other encrypted files). config.require_master_key = true
開発環境で動作検証を行う
ここまでできれば、設定が間違っていないか動作検証を行います。
bin/rails s
アプリが起動することと、ある程度動作することを確認します。
staging環境のRAILS_MASTER_KEYを変更する
先に、staging環境の環境変数RAILS_MASTER_KEYを、config/credentials/staging.keyの値に変更します。
うちではHerokuを使っているので、この設定を先にせずにコードをデプロイして検証しようとしたところ、RAILS_MASTER_KEYの値が異なるためCredentialsが解読できずにデプロイが失敗しました。忘れずにデプロイ前に変更しましょう。
stagingにデプロイして動作検証を行う
ここまでできれば、stagingにデプロイできていると思いますので、動作検証をします。
Encrypted Secretsに関するファイルの削除
問題ないことを確認後、secrets.yml, secrets.yml.enc, secrets.yml.keyを削除しましょう。
これで、あとは本番環境にデプロイすれば大丈夫だと思います。
と思いきや…
落とし穴（RAILS_MASTER_KEYがなくてCIがコケた）
secrets.ymlを削除したことで、CIでコケていました…。うちではCircleCIを使っているので、CircleCIにて、環境変数RAILS_MASTER_KEYを作ってconfig/credentials/test.keyの値を設定したところ、テストも無事に通りました。
忘れずにCIにもRAILS_MASTER_KEYの設定を！！
Macでrails起動時に発生したセグメンテーション違反の原因がわかった
過去に、こんな記事を書いていました。
ずっと騙し騙し、gemの再インストールをしながら使っていたのですが、いよいよresqueがまともに動かないときが頻発したので、ちゃんと調査を開始。
ちなみにこの記事を書いている時点での私のPCの環境は以下の通り。
| 環境 | バージョン |
|---|---|
| OS | Mac OS X Mojave(10.14.6) |
| Ruby | 2.6.3(rbenvでインストール) |
| PostgreSQL | 11.x(Dockerで起動) |
PostgreSQLとの接続を疑う
過去の経緯から、PostgreSQLの接続が怪しいのかなと思っていたら、こんなStack Overflowの投稿を発見。
回答から抜粋すると、以下のような設定（gssencmode: disable）をdatabase.ymlのdevelopmentとtestに追加したらいい、とあった。
default: &default adapter: postgresql development: <<: *default gssencmode: disable test: <<: *default gssencmode: disable
これは、PostgreSQL 12から追加されたオプションらしい。OS Xだとこれの指定がないとエラーになることがあるとか…。
とりあえず設定はしておいたが、PostgreSQLへの接続はうまくいくときといかない時があったので、設定して様子見をしておく…。
Redisへの接続で落ちる
とりあえず、これで直ったんじゃないか？と思い、heroku localコマンドでpumaとresqueを起動させたところ、ActiveJobの処理が動いたらセグメンテーション違反が発生。今度はエラーメッセージが変わった。
13:18:43 resque.1 | /Users/****/.anyenv/envs/rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/redis-4.1.3/lib/redis/connection/ruby.rb:210: [BUG] Segmentation fault at 0x000000010cb14a3a 13:18:43 resque.1 | ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18] 13:18:43 resque.1 | -- Crash Report log information -------------------------------------------- 13:18:43 resque.1 | See Crash Report log file under the one of following: 13:18:43 resque.1 | * ~/Library/Logs/DiagnosticReports 13:18:43 resque.1 | * /Library/Logs/DiagnosticReports 13:18:43 resque.1 | for more details. 13:18:43 resque.1 | Don't forget to include the above Crash Report log file in bug reports. 13:18:43 resque.1 | -- Control frame information ----------------------------------------------- 13:18:43 resque.1 | c:0055 p:---- s:0289 e:000288 CFUNC :getaddrinfo 13:18:43 resque.1 | c:0054 p:0034 s:0281 e:000280 METHOD /Users/****/.anyenv/envs/rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/redis-4.1.3/lib/redis/connection/ruby.rb:210
今度はRedisに接続できなくなっている…。エラーメッセージでググったら、Rubyのバグレポートを発見。
Third Party Issueになっていて、RubyじゃなくてMacのgetaddrinfoのバグのせいらしいことを把握。
同様に色々検索してみたのだが、やはりOS Xのgetaddrinfo由来のバグである、というバグレポートがヒットする。
直す方法が掲示されていないのだが、RubyやGemをコンパイルする時点でバグっていそうだなと思った。
直すためにやったこと
brew upgradeで、gccとかを更新すれば直るんじゃないか？と思い、雑にbrew upgradeを実行。- Rubyを再インストールすれば直るんじゃないか？と思い、雑に
rbenv install -f 2.6.3を実行（ここは任意のバージョンを） - gemを全て再インストールすれば（略）と思い、全てのgemを削除。gemを全削除するのはここを参考にした。 qiita.com
- bundle installを実行
動作確認
heroku local でpumaとresqueを起動させて、ActiveJobの処理を動かしてみたところ、問題なく動いた。また、頻発していたpgのセグメンテーション違反も起きなくなったので、これで解決かもしれない…！！
Hyper-VでAmazon Linux 2を入れる
勉強のために仮想環境を準備しようと思い、Hyper-VでAmazon Linux 2をインストールしてみたのでその備忘録を記します。
目次
イメージをダウンロード
まずは、Amazon Linux 2のイメージをダウンロードします。ダウンロード方法はAWSのページに書いてありますが、色々な仮想化プラットフォームの形式で公開されています。
今回は、Hyper-Vのイメージをダウンロードしました。
seed.iso 起動ディスクを作成する
次に、seed.isoを作ります。これは、Amazon Linux 2が起動したときに自動で設定される項目を定義しておくisoイメージになります。
作り方は先ほどのAWSのサイトに書いてありますが、ここにも書いておきます。ざっくりとした手順は以下の通り。
seedconfigという名前のディレクトリを作成し、そこに移動meta-data設定ファイルを作成するuser-data設定ファイルを作成する- コマンドで
seed.isoファイルを作成する
meta-dataの設定を行う
meta-dataは、ネットワークの設定を記入します。Hyper-Vで動かす場合は、仮想スイッチと同じネットワーク上に作らないといけないので、仮想スイッチのネットワークを調べましょう。
ネットワークの設定を調べる
仮想スイッチのネットワークですが、コントロールパネルのネットワークとインターネット、ネットワーク接続で確認することができます。今回は、前に作ったVagrantで利用するために固定IPを設定した仮想スイッチのネットワークを使います。Default SwitchのネットワークはPCが再起動するたびにコロコロ変わっていたので、とりあえず今回は使いません。なんか固定する方法もあるらしいけれど。
矢印の仮想ネットワーク上で右クリックをして、プロパティを表示します。
そして、インターネット プロトコル バージョン 4を選択して、プロパティを表示。
固定IPが振ってありました。192.168.100.1/24にしていることが、これで確認できました。
DNS設定が抜けていたので、後で家のルーターのIPアドレスを指定しておきました。ここは各自のネットワークに合わせてください。
meta-dataを記入する
local-hostnameは適当に。私の場合はPostgreSQLの勉強用で作ろうとしていたので、postgres.primaryにしました。
network-interfacesは、先ほど確認した仮想スイッチと同じネットワークである192.168.100.0/24に属するように書きます。/24はサブネットマスクのことで、255.255.255.0と同義です。gatewayに先ほどの仮想スイッチのIPを指定します。addressに、192.168.100.10を設定しました。
local-hostname: postgres.primary # eth0 is the default network interface enabled in the image. You can configure static network settings with an entry like the following. network-interfaces: | auto eth0 iface eth0 inet static address 192.168.100.10 network 192.168.100.0 netmask 255.255.255.0 broadcast 192.168.100.255 gateway 192.168.100.1
user-dataの設定を行う
次に、user-dataを設定します。これはAWSのほうで書かれていた通りに。defaultにしておくと、ec2-userが作られます。個別にユーザーを作成したい人は、usersのところで新しくユーザ名を追記すればいいかと思います。パスワードは自分で設定してください。
また、ローカル環境なので、Cloud-initが1度しか実行されないようにしておきました。
#cloud-config #vim:syntax=yaml users: # A user by the name `ec2-user` is created in the image by default. - default chpasswd: list: | ec2-user: *********** # In the above line, do not add any spaces after 'ec2-user:'. # NOTE: Cloud-init applies network settings on every boot by default. To retain network settings from first boot, add following ‘write_files’ section: write_files: - path: /etc/cloud/cloud.cfg.d/80_disable_network_after_firstboot.cfg content: | # Disable network configuration after first boot network: config: disabled
seed.isoファイルの生成
WSL経由で、seed.isoファイルを生成します。WSLにUbuntuを入れてあるので、そちらからコマンドを入力しました。 seedconfigディレクトリに移動後、次のコマンドを実行します。
$ genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data
これで、seed.isoイメージができました。
VMを作成する
ここからがAWSのサイトに書かれていなくて困ったところです。
イメージの移動
まず、ダウンロードしたHyper-Vのイメージを解凍して、Hyper-Vのイメージが置かれるディレクトリ（C:\Users\Public\Documents\Hyper-V\Virtual hard disks）に移動させました。先ほど作ったseed.isoファイルも同様に移動させました。
これは必要なことではありませんが、VMのイメージがどこにあるのかわかりやすくするためです。
仮想環境の構築
次に、Hyper-Vマネージャを起動します。検索から探すとすぐに見つかります。
仮想マシンの作成
仮想マシンの新規作成を選びます。
ウィザードが出てくるので、名前はお好きなものを。とりあえずAamzon Linux 2としました。
世代の指定ですが、第1世代を選びます。これは、AWSで公開されているHyper-Vのイメージが第1世代だからです。
メモリの割り当ては適当に。私は1024MBにしました。
ネットワークの構成は、先ほど参照した仮想スイッチを指定します。
仮想ハードディスクの接続は、最初にダウンロードしたHyper-Vのイメージを指定します。「既存の仮想ハードディスクを使用する」を選択し、さきほど移動させたHyper-Vのイメージを指定しましょう。
あとは、確認して、完了を押してウィザードを終了します。
ブートの設定
次に、作成した仮想マシンのブート設定を行います。これは、先ほど作成したseed.isoファイル経由で起動させるための設定です。
先ほど作った仮想マシンを選択し、右クリックして設定を選びます。
次に、IDEコントローラーを選択し、メディアにイメージファイルを指定し、先ほど作ったseed.isoを設定します。設定が終わったらOKを押します。
仮想環境を起動する
では、起動してみましょう。
Hyper-VマネージャのAmazon Linux 2上で右クリックして起動を選択します。その後、接続を選択します。
ecs-userでログインするところまで確認できました。
sudo yum updateを実行してみたところ、アップデートパッケージも取得できたので、ネットワークの設定もOKなようです。
これで、家庭でAmazon Linux 2を試せる環境ができました。しかし、まだネットワーク経由で接続できません。Hyper-Vの接続を使うのは表示も小さいし面倒過ぎます。SSHできるようにしましょう。以降、Hyper-Vに入れたAmazon Linux 2のことをVMと書きます。
SSHで接続できるように設定する
一時的にパスワード認証を許可
まず、VM上でsshd_configを編集して、一時的にパスワード認証を許可します。これは、ホストOSとゲストOSでクリップボードが共有できないため、公開鍵を追加するのが困難だったためです。
sudo vi /etc/ssh/sshd_configで編集します。コマンドモードで、/Passwordと打ってEnterを押すと、該当の箇所が検索できるでしょう。
# コメントアウトを外す PasswordAuthentication yes
これで保存し、sshdを再起動します。
sudo systemctl restart sshd.service
SSHでパスワードで接続できるようになりました。
Windows側でSSHの設定を追加する
公開鍵・秘密鍵の作成
PowerShellで、以下の通りに入力します。
ssh-keygen.exe -t ecdsa
これで、~/.ssh/id_ecdsa と ~/.ssh/id_ecdsa.pubが出来上がります。
公開鍵をVMに設定する
PowerShellからSSHでVMに接続します。
ssh.exe ec2-user@192.168.100.10
パスワード認証で接続後、VM側の~/.ssh/authorized_keysに、さきほど作った公開鍵 id_ecdsa.pub の内容を追加します。コピー＆ペーストしてください。
終わったら、SSHを切ります。
SSHのConfigを設定する
WindowsからVMにホスト名で接続できるようにするため、設定しておきます。ここで、ユーザ名と秘密鍵の指定を行います。ホスト名は vm_al2_primaryとしました。ここはお好きにどうぞ。
Host vm_al2_primary HostName 192.168.100.10 User ec2-user Port 22 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile "~/.ssh/id_ecdsa" IdentitiesOnly yes LogLevel FATAL
公開鍵接続できるかチェック
では、試します。
ssh.exe vm_al2_primary
これで、接続できたらOKです。
パスワード認証を無効にする
先ほどと逆のことを行います。
VMで、sudo vi /etc/ssh/sshd_configで編集します。コマンドモードで、/Passwordと打ってEnterを押すと、該当の箇所が検索できるでしょう。
# コメントアウトする # PasswordAuthentication yes
これで保存し、sshdを再起動します。
sudo systemctl restart sshd.service
パスワードで認証できないことを確認する
PowerShellで、SSHを試してみます。
ssh.exe ec2-user@192.168.100.10
接続拒否されたら、OKです。
まとめ
WindowsでAmazon Linux 2を使えるようにするまでを書きました。Hyper-Vだとなかなか情報が見つかりにくい印象がありますが、これで勉強が捗りそうです。
2019年を振り返る
年が変わる前に振り返りをしておこうと思う。
今年は育児休暇が終わって復職してから、様々なことに取り組んだ。
技術的な取り組みはそんなに尖ったものはなかったが、GraphQLとOAuth2の勉強やgemを使った実装をやったりなど。
私はマネージャーではないので、中間的な役割がいると思い、開発部全体の垣根をなくしていくための企画をいくつか提案し、実施した。
- 希望者が技術を業務時間に学べる場を作った
- 業務時間後に有志で読書会を開いた
- 金曜のお昼は有志で食べに行くようにした
- 若者のキャリアを考える会を開いた
- 自己紹介発表会を開催した
会話が少ないことが課題だと思っていたので会話を増やすための施策を行った。まぁ昔よりは話しやすい雰囲気にはなったのではないかと思う。
特に自己紹介発表会はよかった。若者は自己紹介をする機会が多いが、古参社員や中途社員はチーム外にはなかなか経歴を話す機会がない。面白かったという感想を多くいただいた。
あとは、まぁここに書くことでもないが、色々と取り組んだ。課題は山ほどあるが…。
登壇は、年末には合同勉強会で発表した。それくらいだろうか…。あ、RubyKaigiのドリンクアップでLTした。しかし騒がしすぎて全然聞いてもらえなかった気がする…。
反省点としては、もう本当にたくさんある。 仕事と家庭のバランスはどうかとか、後輩との接し方はこのままでいいのか？とか、OJTのプランこのままでいいのか？とか、体調管理とか、勉強量とか、インプット、アウトプットの量はどうかとか、ずっと悩んでいる。
それを踏まえて、来年の目標は来年になったら考える。
岡山市周辺の公園・施設を紹介する
この記事は大都会岡山 Advent Calendar 2019の7日目です。
公園・施設を紹介
子供が生まれてから、子供が遊べる公園・施設に行くことが増えているので、今回はそれをまとめてみようかなと思います。順番は、思い出した順です。
サウスヴィレッジ
農作物の販売や、週末にフリーマーケットがあったり、遊べる公園があったりと楽しめるところです。特に芝生の広場はめちゃくちゃ広いので走り回らせられてGood。ファミリーやカップルのみならず、友達同士でバドミントンしてる人たちとかもよくいます。あと、撮影スポットとしてもいいのか、コスプレ撮影している人たちを見かけることもあります。
マーケットでは、お弁当も売っているので、よくここでご飯を食べた後に遊ばせたりします。
灘崎総合公園
サウスヴィレッジの近くにある公園です。ここも広いし遊具が充実しています。ただ、うちの子たちくらいの年齢だとやや早いかな…という感じ。人気の高いところで、家族連れが大勢います。
深山公園（玉野市）
玉野市になりますが、ドライブがてら、よく行く公園です。道の駅と併設されており、ここも野菜・魚介類の販売があります。公園は、ここも遊具が充実していて、結構ボロボロなのもあるのですが、ここ最近で滑り台付きの遊具が新設されました。これが小さい子でも滑られるものと、大きい子が楽しめる大きな滑り台があり、すごくいいです。
ここも芝生の広場が広いので、やや安心です。
それにしてもウェブサイトが20世紀か！！というくらいのやつで驚きました。アクセスカウンターがあった…。
日応寺 自然の森スポーツ広場
岡山空港の近くにあるスポーツ公園です。スポーツ公園なので、野球場とかテニスコートがあり、奥のほうに子供の広場があります。子供の広場は、小さな子供でも楽しめる遊具があります。また、ここも芝生なので安心。ここをオススメするポイントは、噴水と池があるところです。夏場は子供達が水着で池に入って遊びまくっています。そのため、着替えは必須！今年はうちの子達も池と噴水で遊びました。なお、冬場に行くと、まだまだ幼い子供達は冬にも関わらず池に行こうとするので危険です。
あと、空港の近くなので、飛行機の離着陸を見ることができます。子供が見ても大人が見ても楽しいものです。
モンキーパーク
東区にある公園です。みどりの広場という名前らしいですが、遊具に猿のマスコットが描かれているため、モンキーパークという愛称になっているとか。
ここは最近よく行くところで、駐車場の真横に公園があるので移動が楽、かつ、トイレがちゃんとあるのがいいです。
滑り台、シーソー、ブランコ、ジャングルジム、ターザンロープなどがありますが、基本的には中央にある滑り台付きの遊具が人気です。緩やかなローラー滑り台があり、これは小さな子供を滑らせても安心です。
あと、コンクリートの滑り台。結構スピードが出て、時々子供が飛びすぎて泣いてたりします。普通に滑ればそこまででもないんですが。
西大寺緑化公園
これも東区のほうにある公園です。街中にあり、買い物施設が近所にたくさんあるので便利そう。
遊具は多少あるかな～というくらいです。大きな遊具はあるけれど、小学生向けかなと思います。中央に図書館があるのですが、そこに布絵本がたくさんありました。幼児を連れて図書館にいくと、子供が本を破ってしまうのではないか？という不安が常に付きまとうのですが、布絵本なら破れないので安心です。子供向けの絵本の読み聞かせもやってました。
散策用に川のある森があるのですが、こちらは川に子供達が入ろうとして止めるのが大変です。
こどもの森
岡山総合グラウンドや岡山大学から近いところにある、こどもの森です。ここも噴水と池があり、夏場には水着と着替えが必須！ちょっと足場がゴツゴツしていますが、子供達は楽しそうでした。 また、幼児向けの遊具も充実しており、かなり遊ばせることができます。
ただし、街中なので駐車場と道が狭く、人気スポットなので駐車場がすぐに埋まります。行くなら早めか、ピーク時間をずらす等したほうがいいでしょう。
中山公園
児島のほうにある公園です。遊具がかなり充実しており、おすすめのスポットです。トイレも公園の横にあり、ちゃんと管理されているので綺麗めです。
斜面を使ったアスレチック的な遊具があるのですが、うちの子達にはまだ早い…。
玉島みなと公園
ここはたまたまで1回しか行ったことないのですが、遊具が充実していたのを覚えています。人気スポットのようで人がいっぱいでした。
玉島の森
ここもたまたまドライブがてらで1回行きました。あまり人がいなかったのでゆっくりと遊ばせることができたな～という記憶があります。スポーツ公園のため、テニスをしている人たちが多かったです。
円通寺公園
山の上のほうにあり、子供を遊ばせるための遊具はほぼないので、子供を遊ばせるという目的では行かないほうがいいでしょう。古い遊具が多く、事故を防ぐためだと思いますが、使えないように固定されてました（地球儀とか）。
景色はいいです。円通寺というだけあって、お寺の近くなのですが、ここの休憩所で、玉島みなと公園を教えてもらいました。
酒津公園
イオンモール倉敷の裏にある公園です。ここは遊具も充実しているし、水場もあるしで遊ばせやすいところです。
ハイランドマウンテン
高梁市にある超大型遊具です。斜面に迷路のようにずっと遊具が続いていて、楽しい作りになっています。
ただ、斜面を下っていくので、帰るときに上るのが大変ではあります。
ここも1度しか行ったことがないのですが、そのときに長男が遊び始めるまさにその時に、斜面でコケて擦りむいてしまって一気にテンションが落ちてしまい十分に楽しめなかったので、もうちょっと成長してからリベンジしたいところです。
終わりに
もう何か所かあったように思うのですが、思い出せたのがこれくらいでした。まぁ定番で行ってるのはサウスヴィレッジと深山公園くらいで、あとは時々って感じです。
他の方のオススメの公園情報などありましたら、是非教えてください！！