You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-`MINIO_FOLDER_PREFIX_MEDIA`: The `folder` (a prefix really) where your DO Storage and File storage will go inside the `MINIO_BUCKET_MEDIA` Bucket. `media/` is a _fine_ name for this one and common in archipelago deployments. **IMPORTANT:** Always terminate these with a `/`.
148
148
-`MINIO_BUCKET_CACHE`: The name of your IIIF Cache storage Bucket. May be the same as `MINIO_BUCKET_MEDIA`. If different make sure your your `MINIO_ACCESS_KEY` and/or IAM role ACL have permission to read write to this one too.
149
149
-`MINIO_FOLDER_PREFIX_CACHE`: The `folder` (a prefix really) where Cantaloupe will/can write its `iiif` caches. `iiifcache/` is a _lovely_ name we use a lot. **IMPORTANT:** Always terminate these with a `/`.
150
-
-`REDIS_PASSWORD`: Password for your REDIS (Drupal Cache/Queue storage) if you decide to enabled the Drupal REDIS module.
150
+
-`REDIS_PASSWORD`: Password for your REDIS (Drupal Cache/Queue storage) if you decide to enable the Drupal REDIS module.
151
151
152
-
`IMPORTANT NOTE`: For AWS EC2. If your selected an `IAM role` for your server when setting it up/deploying it, `min.io` will use the AWS EC2backed internal API to request access to your S3. This means the ROLE itself needs to have read/write access (ACL) to the given Bucket(s) and your key/secrets won't be able to override that. Please do not ignore this note. It will save you a LOT of frustration and coffee. You can also run an EC2 instace without a given IAM and in that case just the ACCESS_KEY/SECRET will matter.
152
+
`IMPORTANT NOTE`: For AWS EC2. If you selected an `IAM role` for your server when setting it up/deploying it, `min.io` will use the AWS EC2-backed internal API to request access to your S3. This means the ROLE itself needs to have read/write access (ACL) to the given Bucket(s) and your key/secrets won't be able to override that. Please do not ignore this note. It will save you a LOT of frustration and coffee. You can also run an EC2 instace without a given IAM and in that case just the ACCESS_KEY/SECRET will matter.
153
153
154
-
Now that you know, you also know that these values should be not **shared** and this `.env` file **should not** commited/kept in version control. Please be careful.
154
+
Now that you know, you also know that these values **should not be shared** and this `.env` file **should not be committed/kept in version control**. Please be careful.
155
155
156
156
`docker-compose` will read this `.env` and start all services for you based on its content.
Copy file name to clipboardexpand all lines: docs/upgradeFromRC3.md
+85-20
Original file line number
Diff line number
Diff line change
@@ -115,63 +115,113 @@ Time to fetch the `1.0.0` branch and update our `docker-compose` and `composer`
115
115
```shell
116
116
cd deploy/ec2-docker
117
117
docker-compose down
118
+
git fetch
118
119
git checkout 1.0.0
119
120
```
120
121
121
-
Then copy the appropriate `docker-compose` file for your architecture:
122
+
If you decide to enable the Drupal REDIS module, make sure to add the `REDIS_PASSWORD` variable to your `.env` file.
122
123
123
-
<!--switch_below
124
+
`IMPORTANT NOTE`: For AWS EC2. If you selected an `IAM role` for your server when setting it up/deploying it, `min.io` will use the AWS EC2-backed internal API to request access to your S3. This means the ROLE itself needs to have read/write access (ACL) to the given Bucket(s) and your key/secrets won't be able to override that. Please do not ignore this note. It will save you a LOT of frustration and coffee. You can also run an EC2 instance without a given IAM and in that case just the ACCESS_KEY/SECRET will matter.
124
125
125
-
??? info "OSX (macOS)/x86-64"
126
+
Now that you know, you also know that these values **should not be shared** and this `.env` file **should not be committed/kept in version control**. Please be careful.
126
127
127
-
```shell
128
-
cp docker-compose-osx.yml docker-compose.yml
129
-
```
128
+
Now let's back up the existing `docker-compose` file:
129
+
130
+
```shell
131
+
cp docker-compose.yml docker-compose-original.yml
132
+
```
133
+
134
+
Then copy the appropriate `docker-compose` file for your architecture:
As you can see, most of the changes in this example are for new images and a new service/container/environment variable (REDIS), but you may have custom settings for your containers. Review any differences carefully and make adjustments as needed.
173
223
174
-
Finally, pull the images
224
+
Finally, pull the images:
175
225
176
226
```shell
177
227
docker compose pull
@@ -216,7 +266,22 @@ Important here is the `STATUS` column. It **needs** to be a number that goes up
216
266
217
267
### Step 3:
218
268
219
-
Instead of using the provided `composer.lock` out of the box we are going to loosen certain dependencies and bring manually Archipelago modules, all this to make update easier and future upgrades less of a pain.
269
+
Instead of using the provided `composer.default.lock` out of the box we are going to loosen certain dependencies and bring manually Archipelago modules, all this to make update easier and future upgrades less of a pain.
270
+
271
+
First, as a sanity check let's make sure nothing happened to our original `composer.lock` fileby doing a diff against our backed up file:
0 commit comments