It should be possible to explicit name images and containers

I am aware of ongoing discussion about "The project name should be configurable", #45"

However, I think it should be easy to simply name and tag images and containers explicitly, like this:

ubuntu:
  build: dockerfiles/ubuntu
  image_name: nickname/ubuntu:latest
web:
  image: nickname/ubuntu:latest
  image_name: nickname/apache:2.4
  container_name:web

Maybe related:
If directory containing Dockerfile has name not matching [a-z0-9-_.] (i.e. starts with uppercase), build fails with following message:

$ fig up
Creating MyProject ...
Building someservice...
Invalid repository name (MyProject), only [a-z0-9-_.] are allowed

Maybe being able to configure image name will fix this.

@kolen

@kolen I believe you are mistaken. A directory name with an uppercase letter is just fine. Fig will normalize the project name if it contains non-alphanumeric characters.

That error string does not appear in the fig codebase at all. I see that string in docker:registry/registry.go. I suspect it's coming from a registry.

Do you have an image in the fig.yml (or a FROM line in the Dockerfile for someservice) that contains invalid characters as part of the registry name?

I'm experiencing the same invalid repository message as kolen, and only when the directory containing fig.yml has a name with an uppercase letter. This started occurring after upgrading to docker 1.3.0. Happens with both fig 0.5.2 and 1.0.

I can confirm this as well. Docker 1.3.0, boot2docker 1.3.0, fig 1.0. Didn't have a problem with fig 0.5.2 and Docker / boot2docker 1.2.0.

The directory name I was using was called "Docker". I renamed the directory so it starts with a lowercase character and even added a prefix, like "project-docker" and now it works. Fig does seem to remove the - (it gives the images a prefix of projectdocker_), so it does something, but it doesn't change case.

BTW, I'm on OS X.

@dnephin

@dnephin I have build: . in fig.yml and . is directory with uppercase characters in name. Also using Mac Os (with boot2docker).

As I discovered, project name is normalized in get_project_name:

    def get_project_name(self, config_path, project_name=None):
        def normalize_name(name):
            return re.sub(r'[^a-zA-Z0-9]', '', name)
    # ...

Changing it to

diff --git a/fig/cli/command.py b/fig/cli/command.py
index 743c96e..16d02e6 100644
--- a/fig/cli/command.py
+++ b/fig/cli/command.py
@@ -81,7 +81,7 @@ class Command(DocoptCommand):

     def get_project_name(self, config_path, project_name=None):
         def normalize_name(name):
-            return re.sub(r'[^a-zA-Z0-9]', '', name)
+            return re.sub(r'[^a-zA-Z0-9]', '', name).lower()

         project_name = project_name or os.environ.get('FIG_PROJECT_NAME')
         if project_name is not None:

temporarily fixes the problem (at least for directories with uppercase characters — tried, it works, after this change fig builds my project).

Aha, thanks for the extra details! It seems that this is another non-backwards compatible change to the Docker remote API with 1.3.

I think this might be related to this change moby/moby@aabba98.

👍
I very much second the original feature request (the above error is unrelated IMO and should be moved to another issue).

It's very common that you want to create a new image for deployment from time to time. So you need a way to give that image a new version tag. fig should have built in support for this.

As I see it, the only workaround is not to use build in your fig.yml and instead build the image manually with docker build .... And then configure this image as image in your fig.yml.

Fair enough, I guess the discussion of the other issue should move to #571

For the original issue, #457 is a PR for that feature

@mikehaertl

Related to this the automaticly generated image names produces invalid hostnames when used with skydock/skydns. _ is invalid in a hostname so <project>_<service> produces an invalid hostname.

I will likewise look at skydock to see if it's parameterizable how to pick the hostnames of the containers. It currently uses IMAGENAME.ENVIRONMENT.DOMAIN

I'm successfully following @mikehaertl 's workaround to build manually with docker and then executing the images from fig.

@vidarl

concerning explicit container names, see #652

@vidarl, i haven't read everything here and referring en detail, but i'm under the impression that your initial issue is reflected in various others, so this here could be closed!?

@funkyfuture

@funkyfuture : yes, you are right.. Seems like tagging images is covered by #457 and naming containers are tagged by #652. This one can be closed.

No, naming images is still don't supported, and #457 doesn't seem to be the same use case...

Navigation Menu

Repository navigation

It should be possible to explicit name images and containers #541

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

It should be possible to explicit name images and containers #541

Description

Activity

kolen commented on Oct 18, 2014

dnephin commented on Oct 18, 2014

kalmi commented on Oct 19, 2014

petercv commented on Oct 19, 2014

kolen commented on Oct 19, 2014

dnephin commented on Oct 19, 2014

mikehaertl commented on Oct 24, 2014

dnephin commented on Oct 26, 2014

tfoote commented on Nov 12, 2014

funkyfuture commented on Feb 17, 2015

vidarl commented on Feb 18, 2015

anthony-o commented on Oct 2, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions