profile
viewpoint
Roman Anasal acran @BDSU Munich, Germany

acran/InlineVcardBug_bot 1

Source for @InlineVcardBug_bot Telegram bot

acran/webogram 1

Telegram UNOFFICIAL web application, GPL v3

acran/AcademyConsultBot 0

Quellcode für den Telegram-Bot von Academy Consult

acran/caja-extensions 0

Set of extensions for Caja, the MATE file manager

acran/compose 0

Define and run multi-container applications with Docker

acran/docker.github.io 0

Source repo for Docker's Documentation

acran/evince 0

View multipage documents

acran/ionic-NavParams-override-example 0

example code to reproduce ionic-team/ionic#18765

push eventBDSU/admin-scripts

Roman Anasal

commit sha 6a91d82c22071a562a298a0d4fd6a4b767c5c785

[Sync-Guests] Typofix für Integrationsguide-Link im Readme

view details

push time in 7 days

issue commentcompose-spec/compose-spec

Define remote services and depend on them using healthchecks

How about using a local service to verify the healthiness of the remote service like this:

services:
  app:
    depends_on:
      remote_service_monitor:
        condition: service_healthy
  remote_service_monitor:
    # ...

where remote_service_monitor is a simple local container which just monitors the remote service and exposes the results in its own health status. A very simple example to verify a remote web service is up could be:

services:
  remote_service_monitor:
    image: alpine
    # just to keep the container alive
    command: sh -c 'while true; do sleep 999; done'
    healthcheck:
      test: "wget -qO - https://remote.example.com/healthcheck"
k-miras

comment created time in a month

issue commentcompose-spec/compose-spec

Proposal: profiles

Right, maybe this is not such a good idea to magically enable a service when explicitly invoked by name.

Also correct: conceptually this is actually wrong and has some hidden magic in it. But the reason for this is the convenience it provides the users and which makes sense from a UX perspective since it makes docker-compose a really useful tool which does not get in the way of the users^^

ndeloof

comment created time in a month

issue commentcompose-spec/compose-spec

Proposal: profiles

only if you use up command, and not run to just run a single service (and dependencies)

Yes. Which means wanting to start the core services (in this example frontend) by just doing

docker-compose up

would - in this environment - also start mock_backend and database which is undesired since these are intended to be started only on-demand. This becomes a bit clearer when thinking of a "one-off service" or "task" which has dependencies that are only in the same profile(s).

ndeloof

comment created time in a month

issue commentcompose-spec/compose-spec

Proposal: profiles

That's an option indeed, but for such use case I believe we should promote use of distinct composefile per usage, so that users maintain a compose-dev.yaml file to include such mocks and dependent services as long as they aren't relevant otherwise.

This is actually what docker-compose currently does promote - because there is no other way to achieve something like this at the moment - see solution 1. in the opening post of docker/compose#1896. But as the very long discussion and continued requests for such a feature 5 years later clearly show: this is not an adequate solution for many users, and the reason why I opened #87. Because having to know and type out:

compose -f compose-de.yaml up mock_backend
# or
compose up --profile dev mock_backend

is not much of a difference convenience-wise.

Having DOCKER_COMPOSE_PROFILE=dev set in the environment would mean that the mock_backend would be started by default in that environment and not only on-demand. And it would not be a huge difference to COMPOSE_FILE=compose.yml:compose-dev.yml

ndeloof

comment created time in a month

pull request commentcompose-spec/compose-spec

Introduce `profiles`

With the follow-up PR for override files in mind: should we maybe narrow down the valid profile names? These should exclude all invalid characters for filesystem paths and maybe also / and \?

Also having a profile name start with '-' could make parsing command lines hard:

# start profile named "--build"
compose up --profile --build
ndeloof

comment created time in a month

Pull request review commentcompose-spec/compose-spec

Introduce `profiles`

 merged are hosted in other folders. As some Compose file elements can both be expressed as single strings or complex objects, merges MUST apply to the expanded form. +### Profiles++Profiles allow to adjust the Compose application model for various usages and environments. A Compose+implementation SHOULD allow user to define a set of active profiles. The exact mechanism is implementation+specific and MAY include command line flags, environment variables, etc.++All top-level elements support a `profiles` attribute to define a list of named profiles. Elements without +a `profiles` attribute set MUST always be enabled. The enclosing component MUST be ignored by compose+implementation when none of the listed profiles match the active ones, until the target component is+explicitly targeted by a command.++References to other services (by `links`, `extends` or shared resource syntax `service:xxx`) MUST not

See https://github.com/compose-spec/compose-spec/issues/97#issuecomment-685712571

ndeloof

comment created time in a month

PullRequestReviewEvent

issue commentcompose-spec/compose-spec

Proposal: profiles

Hope this makes my proposal clearer :)

Yes, this is exactly how I understood it.

But my example was aiming into the other direction: what if the service depended on is not in the default/always-enabled profile by purpose?

So maybe a new example to make it clearer:

services:
  frontend:
    # this is our core service/the actually application
  mock_backend:
    # a dummy backend used for testing in local development
    profiles: ["dev"]
    depends_on: ["database"]
  database:
    # database for mock_backend
    profiles: ["dev"]
  phpmyadmin:
    # user-friendly frontend to inspect and manipulate the database
    profiles: ["run-never"]
    depends_on: ["database"]

Here the phpmyadmin service is intended to only ever be started manually. But starting it with

compose up phpmyadmin

would fail because its dependency database is not in the default/always-enabled profile and therefore can not be satisfied.

One could argue here that it is the configuration author's responsibility to assign dependent services common profiles and so far I could agree with that. But this still wouldn't work in the following case:

compose up mock_backend

Although mock_backend and database are in the same profiles this would fail because database was not explicitly provided according to the current proposed spec change:

References to other services (by links, extends or shared resource syntax service:xxx) MUST not automatically enable a component that would otherwise have been ignored by active profiles.

The only ways to start the service would be:

compose up --profile dev mock_backend
compose up mock_backend database

Which again would require the user to know or lookup the correct profile for the requested service and all its dependencies or explicitly provide all (transitive) dependencies. Since this "little" inconvenience was the major pain point in the discussions at docker/compose#1896 I propose this change

References to other services (by links, extends or shared resource syntax service:xxx) MUST automatically enable a component that would otherwise have been ignored by active profiles.

Or as a compromise only the profiles of the explicitly enabled services should be activated as well, as suggested by @EricHripko:

References to other services (by links, extends or shared resource syntax service:xxx) MUST not automatically enable a component that would otherwise have been ignored by active profiles unless they share a profile with a component explicitly targeted by a command.

For a reasonably good written compose file this would effectively be equivalent to the former and provide a sufficient and intuitive convenience for the users.

ndeloof

comment created time in a month

issue commentcompose-spec/compose-spec

Proposal: profiles

environment variables allow to tweak a compose file with distinct values, but not to apply significant changes. compose file overrides allow to redefine a volume

Using COMPOSE_FILE environment variables already allow to pull in additional overrides and so also apply significant changes.

In your sample of a compose file with 14 services, and user who wants to run only 3 of them, I hardly can imagine why this compose file has 14 services, which should not be declared as specific to a profile to cover an explicit use-case.

Because the user wants to - which doesn't necessarily mean the compose model has to support this use case. So this example was made to visualize the "problems" in such edge cases to be better able to decide if that uses cases should be supported anyway.

A compose file should be use to define an application model, not just as a generic bag to define random stuff and cherry-pick the one you'd like to run.

I didn't consider it that way, but agreed.

Proposal indeed covers two approaches:

Coming from #87 for me the first approach would be enough and no need for the second. But as long as this proposal covers the first one I'm happy with both :smile:

About one-off tasks, your sample uses an explicit service being passed as parameter. In such circumstances we can clarify that such an explicit service reference do enable this service, whenever it has been disabled for inactive profile.

Looking at the most requested use cases in docker/compose#1896 this is a very important clarification that should be included here so these use cases can be supported.

Correct me if I'm wrong, but It seems like this proposal suggests that * (or default since it seems like the difference is just naming) profile is for services that are always on. This means that the suggested Compose file could look like:

Not really: the database is explicitly assigned to the default profile - only. To better clarify the point replace default with any other profile e.g. backend. Starting the migrations service would then require this command:

compose --profile one-off --profile backend run --rm migrations

But the desired command line should be just

compose run --rm migrations

because having to type out everything explicitly and having to memorize/lookup the correct profile(s) for all services and dependencies makes it very inconvenient.

Therefore I would like to extend to

In such circumstances we can clarify that such an explicit service reference do enable this service and its dependencies, whenever it has been disabled for inactive profile.

But this would be great to also cover and resolve the use case of #87.

ndeloof

comment created time in a month

startedsarcaustech/chrome-extension-studenten

started time in a month

issue commentcompose-spec/compose-spec

Proposal: profiles

Playing around with the profiles concept and its edge cases in my head I have some more thoughts on this. But small disclaimer here: coming from the desire to just disable some services from being started by default (#87) I may be a bit biased towards some use cases here.

coupling profiles with override yaml files

Currently this proposal does two things:

  1. introduce the profiles attribute to services
  2. add rules to automatically include additional overrides for profiles

But I don't feel like 2. is actually necessary to solve to problem we're addressing here: the main reason why users currently use multiple yml files (in this scenario) is because there is no other way to specify services but don't let them be started automatically. The introduction of the profiles attribute (1.) solves this now and allows to just specify all services and one-off tasks in a single compose.yml and select them with the --profile flag, eliminating the need for multiple compose.yml files.

It's also a common practice to have separated override compose file to address different environments, typically to configure some services with debug port exposed during development.

This I see as a separate thing because it is about environment-specific changes. For these there already is an established solution: environment variables and the .env file where one could e.g. specify COMPOSE_FILE.

In my opinion not mixing profiles and environments but keeping them independent would offer the most flexibility to the user and therefore this part should be dropped from the proposal - especially since this requires to first add overrides to the spec.

But if this will be included I would propose a naming convention of compose-overrides.[profile].yml to emphasize that it is used to override/extend already defined services with profile-specific stuff. This would also avoid this edge case:

there's just the compose --profile overrides up case to define.

default value profiles: ["*"] vs profiles: ["default"]

I'm still a bit undecided on this one: I find

--profile profile-name start services that have profile-name listed in their profiles only. If not specified, profiles defaults to ["default"]

much more intuitive - and probably also easier to implement since there is no special handling of unspecified values other than the default value - than

--profile profile-name start services that have profile-name listed in their profiles or have no profiles specified

Take for example a compose.yml with 14 services. The user now wants to define and start a profile "dev" with only 3 of the services: With a profiles: ["default"] default value the user only needs to add profiles to those 3 services:

docker-compose up --profile dev # start only the 3 dev services

# start dev services _and_ default services
docker-compose up --profile dev --profile default

With a profiles: ["*"] default on the other hand the user has to explicitly specify profiles: ["default"] to all other of the 14 services (and possibly in all override files) to achieve the same.

One could of course argue in such a case it is easier to split those 3 services into their own compose.yml. But with dependencies to other services/sharing with other profiles this may lead to duplication or back to the mess with needing to include multiple compose.yml we wanted to avoid with this proposal.

--profile as filter

what does this imply for services not matching the current profile but pulled in by depends_on from another service that is?

I'd prefer we don't include too much magic and consider profiles as a "filter" applied on yaml file to include/exclude services, so that a missing reference is considered an error, and not an "implicit profile".

it'd make sense for profiles to return an error if a dependency (depends_on, service: mode for ipc/pid/network etc) isn't included explicitly

I'd agree on this but I found some problems with it: One of the most requested use cases for this feature is to be able to specify "one-off" tasks or services which are not started by docker-compose up but only explicitly - see discussion in docker/compose#1896 and the opening post

Many users define in a compose file some additional container that they use during development as "one-off" tasks using docker-compose run command, but are not part of their compose application.

For this consider the following (abbreviated) compose.yml:

services:
  database:
    profiles: ["default"]
    # ...
  migrations:
    profiles: ["run-never"]
    depends_on: ["database"]

(in reference to comment on docker/compose#7539)

docker-compose up will only start the default services, i.e. database. The migrations service/task is intended to be only started explicitly. But what happens when you run docker-compose up migrations or docker-compose run migrations?

  • will it start migrations and database as its dependency?
  • will it error out since migrations is not in the default profile?

The latter one means that one must specify the correct profile: docker-compose up --profile run-never migrations But then this would error out because the database dependency is not in the run-never profile and one must use docker-compose up --profile run-never --profile default migrations

This not only is much more to type but also requires the user to remember/look up which profile(s) the desired service/task and all its transitive dependencies belong to - which is exactly what users want to avoid see docker/compose#1896.

Instead of a "filter" over the available services I would understand profiles more of a definition of the default services which should be started when no services are explicitly given including their dependencies. Therefore I also see the --profile flag as a flag to the up subcommand (and create) and not the docker-compose main command.

In this interpretation profiles may be not the best term for this. Maybe something like target would be a better name?

ndeloof

comment created time in a month

issue commentcompose-spec/compose-spec

Proposal: profiles

Compose implementations whith profile support MUST ignore services which have a profile attribute but don't match the current profile.

To clarify: what does this imply for services not matching the current profile but pulled in by depends_on from another service that is? Would this result in an error because the dependency could "not be found" or would it be started anyway?

ndeloof

comment created time in a month

issue commentcompose-spec/compose-spec

Proposal: profiles

If not set, it will default to profiles: ["default"]. [...] Services without a profile attribute always match.

This somehow is contradicting: if profiles defaults to ["default"] services without specified profiles would start only for default. To bring this in harmony with the second statement the default should be something like profiles: ["*"] (pseudo-syntax).

But maybe defaulting to profiles: ["default"] could be better anyway? For example having a profile frontend_only:

  • with default profiles: ["default"] you only have to add profiles: ["default", "frontend_only"] to the frontend services
  • with default profiles: ["*"] you additionally have to add profiles: ["default"] to all other services

Also the implementation could be more straight forward in the former case since there is no special handling besides the default value when unspecified.

Another question to clarify is: how should profiles be merge with overrides? Looking at the current behavior for other multi-value options override values should be added to base values. On the other hand it might useful to be able to remove a service from a profile with an override?

ndeloof

comment created time in a month

issue commentcompose-spec/compose-spec

Add option to specify services to be started by default

@malyzeli

But isn't the objective of this feature request just that we DO NOT have to manage multiple configuration files and merge them manually?

The objective here is to find some way to define the default set of services to be started by a simple docker-compose up - nothing more. So this is only partially true in that we don't want to have to merge them manually - everything else is up for debate.

Maybe I'm wrong, but in my opinion clinging to compatibility with config merging essentially contradicts the purpose of profiles in itself.

You can either define profiles or create multiple compose files, but why would you need both when they basically serve the same purpose?

I don't think that these two feature need to be mutually exclusive but can coexist perfectly well. Even when just executing docker-compose up one may be using multiple configuration files, i.e. by defining the COMPOSE_FILE environment variable e.g. in the .env file.

But my intention was not to rule out this approach but rather to point out the pros and cons of each of them.

acran

comment created time in a month

issue commentcompose-spec/compose-spec

Add option to specify services to be started by default

@malyzeli what you describe would be option 1. from the opening post:

  1. provide a file-wide (white)list of services to be started by default, which when not specified defaults to all defined services

In terms of readability and a centralized overview this has some advantages. But when using multiple docker-compose.yml files this gets confusing pretty quick and thus hard to implement. Consider the following files:

# compose.yml
services:
  frontend:
    # ...
  frontend-dev:
    # ...
  backend:
    # ...
  database:
    # ...
profiles:
  default: ["frontend", "backend", "database"]
  dev: ["frontend-dev", "backend", "database"]
# compose.utils.yml
services:
  phpmyadmin:
    # ...
profiles:
  dev: ["phpmyadmin"]

Now, what would be the expected outcome when one executes

docker-compose -f compose.yml -f compose.utils.yml up

compose.utils.yml overrides compose.yml but does not specify a default profile. So will it result in

  1. the default profile being empty => no services started
  2. fall back to the value in compose.yml => frontend, backend and database started
  3. result in "unspecified" i.e. all services being started

Another example: what should happen when one executes

docker-compose -f compose.yml -f compose.utils.yml up --profile dev

The dev profile in compose.utils.yml only includes phpmyadmin which is defined in the file itself. Should this now

  1. merge with the array in compose.yml resulting in ["frontend-dev", "backend", "database", "phpmyadmin"]
  2. override the whole profile resulting in just ["phpmyadmin"]

With 1. you lose the advantage of a centralized overview under the profiles keyword since it is now scattered over multiple files and also it makes it hard/impossible to remove services from a profile by overriding. With 2. you'll have to always update all docker-compose.yml files when adding/removing a new service, introducing a new dependency between them.

This is why I think the complexity and unintuitive behavior of this approach (1.) outweights its benefits. The same arguments can be applied to approach 2. (a file-wide blacklist).

acran

comment created time in a month

push eventBDSU/workshops

Roman Anasal

commit sha 9f95f28dbd5c146fb6e0b510040bf9f9d718b113

[apache] Slides mit Best Practices ergänzt

view details

push time in 2 months

push eventBDSU/workshops

Roman Anasal

commit sha e33e106de6c2c551fa9029e2aa40647904dd7a0b

[apache] Folien für Webserver-Konfiguration mit Apache

view details

push time in 2 months

PR opened ionic-team/ionic-docs

fix(color-generator): update colors from CSS

This fixes a bug that currently does not to allow to import values as CSS.

Steps to reproduce

  1. go to the color generator page (https://ionicframework.com/docs/theming/color-generator)
  2. scroll down to the CSS Variables section
  3. edit the CSS, e.g. by pasting previously generated colors

What is expected

The colors in the inputs should be updated accordingly as well as the colors in the demo app.

What actually happens

Nothing.

What was the reason

Obviously the code expected the CSS text input to be a textarea but actually it is a div with [contenteditable=true] which is why ev.target.value will always evaluate to undefined and so value.length will throw an exception: https://github.com/ionic-team/ionic-docs/blob/bdf3a610a72783567e5c8868101dbd1bcf214176/src/components/color-gen/css-text/color-gen-css-text.tsx#L19-L21

+3 -3

0 comment

1 changed file

pr created time in 3 months

create barnchacran/ionic-docs

branch : fix-color-gen-css-import

created branch time in 3 months

issue commentionic-team/ionic-docs

Color Generator not updating -shade and -tint when replacing with a value without hashtag

I tracked down the reason for this to this block: https://github.com/ionic-team/ionic-docs/blob/bdf3a610a72783567e5c8868101dbd1bcf214176/src/components/color-gen/variable-selector/color-gen-variable-selector.tsx#L48-L51

The fix should be to simply drop the return since it will still ensure that the input starts with a # and if it not yet a valid input (i.e. 7 characters long) it will be skipped by the subsequent check anyway: https://github.com/ionic-team/ionic-docs/blob/bdf3a610a72783567e5c8868101dbd1bcf214176/src/components/color-gen/variable-selector/color-gen-variable-selector.tsx#L58

It would also need to update val, too, and declaring it with let instead of const. So the fixed code would be:

    let val = input.value.trim();

    if (input.matches('[type="text"]') && val[0] !== '#') {
      input.value = '#' + val;
      val = input.value;
    }
noahhorlacher

comment created time in 3 months

push eventBDSU/admin-scripts

Roman Anasal

commit sha 9b1134105f3c5b61d74debbbfd2879d34efb2888

[Sync-Guests] manuelle Ausführung ohne password.txt ermöglicht Wird das Skript ausgeführt, ohne dass die Zugangsdaten in einer password.txt abgelegt sind, wird jetzt interaktiv danach gefragt

view details

push time in 3 months

issue commentcompose-spec/compose-spec

Add option to specify services to be started by default

I personnaly prefer a profile approach as this one offers more flexibility than a boolean "auto_up" to cover more use-cases (dev/test/debug/cleanup...)

Following a profiles approach auto_up: true / omitting would map to a profiles: ["default"] on the service, auto_up: false would map to profiles: [] or a dummy profiles: ["never"]. So auto_up is just a special case of the profiles approach, i.e. that approach would indeed support even more use cases :+1:

acran

comment created time in 3 months

more